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ABSTRACT 


The Maritime Operations Centers (MOCs) are an integral part of the Navy’s Maritime 
Headquarters (MHQ) concept for Command, Control, Communications, Computers, 
Intelligence, Surveillance and Reconnaissance (C4ISR) structure. The purpose of this 
study was to determine if the mission of the MOC could be accomplished with the 
existing C4I systems assigned. By tracing functions to systems, gaps were identified 
which created a foundation to investigate whether systems currently in development were 
available to meet these gaps. In some cases, candidate C4I systems were proposed to fill 
gaps. System functionality overlap was also noted. 

As a by-product of our research into the MOC concept and analysis of its required 
functions and candidate component systems, we have proposed a methodology for future 
work in the design of the MOC architecture. Through the use of requirements analysis 
tools, we have been able to structure the requirements, functions and proposed systems of 
the MOC architecture in a way that automates the tasks of functional analysis and system 
architecture design. Future work on the MOC requirements and architectures should 
utilize these or similar automation. 
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EXECUTIVE SUMMARY 


The Maritime Headquarters with Maritime Operations Center (MHQ with MOC) concept 
was envisioned as a way for the Navy to standardize the command structure in order to 
support naval, joint, and multinational roles and responsibilities at an operational level 
while maintaining the flexibility to act as Navy component commanders, Navy forces 
commanders, joint force maritime component commanders (JFMCC), and joint task force 
commanders (JTF CDR). Before the MHQ concept, operational-level commands each 
had differing processes and procedures on how to transition between operational roles, 
with ad-hoc training occurring as roles were assigned. The MHQ with MOC concept 
allows for a standard baseline of processes and procedures for managing fleet forces and 
conducting operations with trained personnel able to execute tasks in any of several 
MHQs across the globe. 


The MOC, with a standard baseline of Command, Control, Communications, Computers 
and Intelligence (C4I) component systems, is essential to the scalable, orderly 
management of the operational activities of the MHQ. The MOC houses the tools that 
the MHQ requires to execute its mission, providing collaboration tools, communications, 
situational awareness, and command and control utilities. These tools enable the MHQ to 
assess, plan, and execute the operational objectives of the MHQ commander. The MOC 
consists of both land-based elements within the MHQ and forward shipboard elements 
for responses to areas of crisis. 


A C4I baseline of MOC systems has been proposed by the Program Executive Office for 
C4I (PEO C4I). It is encompassed in a Spiral approach to fielding, with full capabilities 
estimated in Fiscal Years 2012-2015. Spiral 8 consisted of the fielding of the majority of 
existing C4I systems for Command and Control including the Global Command and 
Control System (GCCS) Family of Systems including Maritime (M); Integrated Imagery 
and Intelligence (13); and Joint (J). Spiral 10 provided additional networking capabilities 
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and upgrades to the MOC systems. Further Spirals will bring the MOC in line with 
Consolidated Afloat Networks and Enterprise Services (CANES) and incorporate items 
from Maritime Domain Awareness (MDA) Spirals as those capabilities become 
available. 


As the architecture of the MOC was developed according to the Department of Defense 
Architecture Framework (DoDAF), the process flows of the MOC were documented in a 
set of architecture artifacts. Documents contained lists of operational activities and tasks 
required for their completion. To ensure these tasks and activities would be covered by 
the recommended C4I systems, it was necessary to trace the process flows to the 
component system level and observe gaps and overlaps in how the required tasks were 
accomplished. 


Utilizing architecture design software tools, we were able to trace the originating 
requirements from items in the Universal Joint Task Lists (UJTL) to the component 
system level. The use of automated tools is highly recommended for future work on 
MOC requirements as it allowed for concise graphical displays of the functions of the 
MOC and easy identification of gaps in the capabilities of available systems. It also 
allowed for construction of system views and other architecture products from a common 
database. 


The results of our analysis found several areas where gaps existed, meaning that currently 
available C4I systems were unable to meet the required tasks of the MOC. In some cases 
the activity was described in earlier documents as being completed solely through the use 
of a computerized tool, but the team’s analysis determined it to require more specialized 
work with human involvement. 



This report is organized into five main sections. Section I, the introduction, describes the 
MHQ with MOC concept origins and background for this project, with a breakdown of 
the MOC core processes. Section II describes the research conducted by the group for the 
production of this work and the completion or our tasking. Section III describes the 
methodology applied to our work and the systems engineering approach used in this 
project. Section IV provides the validation of the methodology through the analysis of 
the core process flows and component systems. The final section provides a summary, 
conclusions, and recommendations for future analysis of the MOC concept. 
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1 INTRODUCTION 


1.1 PROBLEM STATEMENT 

Operations conducted over the past decade have identified gaps in the Navy’s Command 
and Control (C2) capabilities needed to support modern Navy doctrine. Naval combatant 
operations, joint operations, and humanitarian relief missions have been severely 
hampered by these shortfalls. Capabilities that have exhibited limitations include the 
following: 

• Ability to command in a dynamic environment. 

• Ability to rapidly identify necessary participants or communities of 
interest across echelons for planning and response to crisis action. 

• Ability to efficiently collaborate and receive rapid feedback to assess and 
adapt to emerging conditions and shortened planning/execution timelines. 
(U.S. Fleet Forces Command, 2007) 

The Navy’s answer to these shortfalls is the establishment of Maritime Headquarters with 
Maritime Operations Centers (MHQ w/ MOC) to effectively execute the necessary 
operational missions while eliminating the identified C2 gaps. The standup of the MOCs 
was the first step in this process, but non-standardized systems and procedures have 
contributed to some of the gaps that were to have been eliminated. Commanders utilized 
the systems already present or individually acquired systems from PEOs that partially 
fulfilled some identified mission requirements. There was little or no consideration for 
interoperability between systems within or between MOCs and no System of Systems 
analysis has been conducted to identify the complete set of functions or requirements the 
MOCs must perform. These are essential steps in the process of designing and 
implementing MOCs that will efficiently and effectively conduct the required missions. 
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1.2 CAPSTONE PROJECT DESCRIPTION 


System analysis tools were used to identify gaps and overlaps in capabilities by tracing 
the MOC architecture to the component level. Through the use of the tools, the tasks as 
described in the Universal Joint Task Lists (UJTL) were mapped to the MOC functions 
and the individual Command, Control, Communications, Computer and Intelligence 
(C4I) component systems identified to execute those functions. Systems planned for the 
MOC Spiral 8 and Spiral 10 baselines were examined to detennine whether they were 
able to accomplish the functional requirements. Where no component systems were able 
to sufficiently meet the requirement, gaps were noted. Similarly, where several systems 
meet the same requirements, the overlap was noted. Issues discovered during the 
analysis regarding tasks assigned to the MOC are described in detail in Section 4. 


In an effort to apply a systems engineering approach to our work with the MOC concept, 
different approaches to systems engineering were compared for consideration. The 
“variations” listed in Blanchard and Fabrycky (2006) provided several approaches that 
could be appropriate, but the one selected to support the development of the MOC 
concept was quoted by Blanchard and Fabrycky from the Department of Defense (DoD) 
Regulation 5000.2-R of 2002. The definition quoted by Blanchard and Fabrycky is as 
follows: 


An approach to translate operational needs and requirements into operationally 
suitable blocks of systems. The approach shall consist of top-down, iterative 
process of requirements analysis, functional analysis and allocation, design 
synthesis and verification, and system analysis and control. Systems engineering 
shall permeate design, manufacturing, test and evaluation, and support of the 
product. Systems engineering principles shall influence the balance between 
performance, risk, cost and schedule (Blanchard & Fabrycky, 2006). 
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Inconsistencies with applying this approach have been identified in both previous and 
ongoing Navy efforts to develop the MOC concept. Regardless of the approach that was 
chosen for the MOC development, the “common threads” of systems engineering present 
in all definitions appear to be lacking. Blanchard and Fabrycky also cite some of the 
“special areas of emphasis” that should be noted in conducting systems engineering. 
They state: 


A better and more complete effort is required regarding the initial definition of 
systems requirements, relating these requirements to specific design criteria, and 
the follow-on analysis effort to ensure the effectiveness of early decision making 
in the design process. The true system requirements need to be well defined and 
specified, and the traceability of these requirements from the system level 
downward needs to be visible (Blanchard & Fabrycky, 2006). 


The lack of requirements traceability for the process flows of the MOC, as defined in the 
currently available operational event-trace description (OV-6c) and other documents, as 
well as an absence of approved fonnal documentation on which to base future, lower- 
level system design, has resulted in the inability to determine appropriate system 
baselines that guarantee the presence of the functional capabilities necessary to 
successfully conduct the MOC mission. These issues are covered more in depth in 
Section 3. 


1.3 BACKGROUND 

1.3.1 MHQ with MOC Concept 

The MHQ with MOC concept was envisioned to standardize the processes and 
procedures in which a Navy Combatant Commander assesses, plans, and executes 
activities at the operational level (U.S. Fleet Forces Command, 2007). Vice Admiral 
M.G. Williams, Jr., former Deputy Commander U.S. Fleet Forces Command, stated the 
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overall purpose of implementing the MOC concept is “to provide common processes and 
methods to allow different Maritime Headquarters to evolve towards standardization of 
assessment, planning and execution at the operational level of war.” (U.S. Fleet Forces 
Command, 2007). It enables the Combatant Commander to effectively fight the Global 
War on Terror (GWOT) and manage Naval assets while remaining flexible enough to 
adapt as necessary to crisis situations as they arise. Each MHQ would be part of a global 
network enabling high-speed net-centric communications, collaboration, and data 
sharing. Standardization of MHQ processes and procedures would allow for coordinated 
training of MHQ staff and a baseline standard set of component systems used in the 
MOC. MOCs would have the ability to scale operational activities to respond to crisis as 
they arise and return to normal operations when they are resolved. 


Figure 1 depicts the staffing of the MHQ, which handles both Fleet Management 
activities and Operational-Level activities, both of which are aided by a shared support 
staff with specialized skills that can be tailored given the Combatant Commander’s 
(CCDR’s) operational environment. 



PKlavy Comport emCDR(NCC-CCDR 
Numbered Fleet COR (« Fleet CDR)< 
Principal HQ CDR (Pnn HQ COR) 


T I M E HEADQUARTER 


Joint Task Force CDR (JTF COR)^ 

- Fu n cton al Component CDR (JFMCCJ 

- Nff»y Service CompooentCOR (JFNC 




’ *s ess igned m Forces For 


wr>en oesjpnefedby 
JFC 


MHQ CDR 


Fleet & Ops 

Navy Service Functions Operations 
_ Functions Functions 


Figure 1 - MHQ Staffing and Roles 

This diagram highlights the dual role of the MHQ with responsibilities in the Fleet 
management and Operations. (Department of the Navy Chief Information Officer) 
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The MOC component of the MHQ was envisioned as a system-of-systems, (SoS) both 
physical component systems and staff personnel, who would be assigned to various cells, 
bureaus, or working groups, coordinating as needed to perform the various activities of 
MOC operations. The MOC would act as a process-driven entity following the paradigm 
of Assess, Plan, and Execute (U.S. Fleet Forces Command, 2007). This paradigm, 
although not aligned exactly with the Navy’s Command and Control doctrine, does fulfill 
the intent (Naval Doctrine Publication 6 (NDP 6), 1995). In this way, a MOC would 
continually assess the overall naval environment within the area of responsibility (AOR) 
as it pertained to operational objectives. Based on those assessments, the MOC would 
plan activities to meet operational objectives and monitor their execution by subordinate 
tactical forces, then assess the effects of those operations. 


1.3.2 MOC Core Processes 

In order for the MOC to perfonn the necessary functions for operational-level operations, 
a set of standardized core processes was developed following the guidelines of Joint 
Capabilities Alignment (JCA) and derived from the UJTFs (Joint Staff, 2008). These 
core processes form the bulk of operations to be performed by the MOC and, as listed 
below, form a baseline that can be scaled if the situation warrants. They were developed 
further within the architecture products that included Operational Views (OV), System 
Views (SV), and Activity Views (AV). The OV-6c relates the tasks and activities 
necessary to accomplish the process flow. 


The MOC Core Processes used in this analysis were taken from the OV-6c 
documentation and are provided in Table 1 with a brief description. 
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Table 1 - Core Processes Descriptions 


Core Process 

Description 

Assess Effects 

A continuous assessment of the effect of current missions and 
operations conducted by the MOC, going beyond initial success 
or failure indications to assess whether follow-on action is 
necessary and how changing environment and battlespace 
affects the operating scenario. 

Operational Intelligence 

Determine what critical intelligence information is needed to 
complete operational objectives, bringing to bear all intelligence 
gathering assets at the MOCs disposal. 

Operational Planning 

Operational Planning is used to ensure that employment of 
forces is mapped to operational and mission objectives. Allows 
for coordination of Naval operations in joint force activities. 

Manage Information 

Ensure that the command has the information necessary to 
complete operational and mission objectives will 
managing/minimizing information overload. 

Establish HQ 

Perform all necessary tasks to setup a MHQ command structure, 
establish decision authority and delegate mission planning and 
execution organizational authority 

Execute Plans 

Oversees and monitors the execution of plans, assess their 
performance and adapt as necessary. 


1.3.3 Approach 

The methodology chosen to guide our efforts consists of a five-phase approach 
incorporating the systems engineering principles discussed earlier. Efforts were 
organized into research, requirements, relationships, analysis and conclusion. Each phase 
accomplished a specific purpose that supported each subsequent phase. Even though 
timelines were established for each phase, this only changed the focus of efforts by team 
members. Continued work on previous phases did not stop entirely. For instance, 
research continued throughout the entire life of the project, but the bulk of the effort was 
accomplished early on. Details of each phase are addressed in Sections 2 and 3. 
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2 RESEARCH SUMMARY 


2.1 OVERVIEW 

The first objective was to gain an understanding of the Maritime Headquarters with 
Maritime Operations Center (MHQ/MOC). The key questions to answer were 1) what is 
a MOC, 2) what is the purpose of the MOC and 3) what are the operations and functions 
of the MOC. To answer these questions the team started basic information gathering. 
Team members began searching the internet, using Google, Yahoo, and other search 
engines for both commercial and military references. The online Dudley Knox Library at 
the Naval Postgraduate School was utilized, including database searches and librarian 
assistance. 

Team members began working with the MOC Working Group, mostly involved with the 
MOC Architecture Integrated Product Team (IPT), reviewing documents and 
interviewing its members. The team met with the sponsor, LCDR Bill Brown, Deputy 
for the Space and Naval Warfare Systems Command (SPAWAR) Model & Simulation 
department, for his input on the history and current direction of the MOC. Over the 
course of the project, team members also met with several Subject Matter Experts 
(SMEs) from SPAWAR to include the Technical Director, Dr. Bill Rix; Chief Systems 
Engineer for Networks, Raymond Buchholz; and Chief Systems Engineer for Large 
Decks, Michael Davis. The team also met with our advisor John “Mike” Green on 
several occasions to gain insight on the MOC and to structure and focus the effort of this 
project. 

Once the team had answers to the key questions, the research focused on gaining 
knowledge of the requirements driving the MOC concept. These driving requirements in 
turn lead to the establishment of a process and methodology for determining the 
capabilities, or lack of capabilities, defined in current MOC documents. 
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2.2 SCOPE AND DEPTH 


Numerous documents and articles were collected and reviewed to gain insight and 
knowledge on the MHQ/MOC. The bibliography section of this document lists the 
documents reviewed for the development of this report. The documentation collected 
ranged from presentations, articles, requirement documents, and minutes. Among the 
references collected, the following documents were extremely useful in providing the 
overall requirements: UJTLs, architectural views (SV-4a, SV-5a, SV-8, OV-6c), 
MHQ/MOC Concept of Operations (CONOPS), and the MOC System Descriptions 
document generated by PMW-790 and provided by Raymond Buchholz, the SPAWAR 
Chief Systems Engineer for Networks. 

This research led the team to review the CORE® Architecture Definition Guide (DoDAF 
vl.5) documentation. The team decided to use CORE* 5.1.5 due to its capability of 
developing operational architectures based on the MOC CONOPS. The operational 
architecture for MOC also required the team to enter the system and process requirements 
into the CORE* application. CORE 8 is capable of producing architectural views of the 
MOC, allowing an analysis of the capabilities and functions. The team utilized the 
graphical views generated in CORE® to identify gaps in the capabilities of the MOC as 
provided by the systems included in the implementation of the MOC concept. 


2.2.1 Research Phase 

The goals of the research included gaining familiarity of the MOC concept, the history of 
events leading to the fonnal initiation of efforts in the development of the MOC concept, 
the requirements driving the development of the MOC concept, the level of effort 
expended to date on development, and the current state of execution. The focus was on 
the military sources, but included research on commercial influences. Sources included, 
but were not limited to, interviews of stakeholders and subject matter experts, personal 
involvement in IPTs, the use of the World Wide Web, program office document 
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repositories, and the Naval Postgraduate School online library and journal search 
capabilities. 

Early research exposed the team to various IPT artifacts including architecture products. 
The most relevant of these architectures were the System Views and Operational Views 
provided by the Architecture IPT. These artifacts quickly became the foundation of our 
research, allowing us to scope our efforts into a manageable undertaking. The views 
most influential in our research included the SV-4a, SV-5a, SV-8 and OV-6c. The draft 
nature of each artifact limited their value, but highlighted the fact that development of the 
MOC concept is being driven forward without solidified requirements and with 
inadequate architecture descriptions. The lack of a formal requirements document was 
confirmed in a discussion with the Navy’s Chief Systems Engineer (CSE) for Large 
Decks (Davis, 2009). CSEs are responsible for conducting Technical Authority reviews, 
representing the SPAWAR Chief Engineer. 

G. Derrick Hinton, Chainnan of the International Test and Evaluation Association, stated 
the importance of architectures in the systems engineering process and for expanding 
beyond point solutions “by creating an architecture as the central aspect of the 
requirements and design process.” He further stated the role of architecture as the 
“bridge from requirements to design, in which the most important, critical or abstract 
requirements are used to detennine a basic segmentation of the system.” (Hinton, 2006) 

Without validated requirements, a relevant architecture cannot be developed. The desired 
end state cannot be accurately expressed without the relevant architectures. The 
architectures are the “blueprint” for moving beyond a concept. Just as a house can be 
built without blueprints, so can a system, but what is the reliability of the outcome? To 
further complicate the situation, the MOC concept requires implementation of a System 
of Systems. Although numerous definitions of a SoS exist, the following is most closely 
applicable to the MOC concept: 
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In relation to joint warfighting, system of systems is concerned with 
interoperability and synergism of Command, Control, Computers, 
Communications, and Information (C4I) and Intelligence, Surveillance, and 
Reconnaissance (ISR) Systems. Primary focus: Information superiority. 
Application: Military. (Manthorpe, 1996) 

The complexity of SoS relationships, accommodating interoperability and system 
interfaces, cannot be accurately described without architectures. The relationship 
between elements and interfaces is not a one-to-one relationship. On the contrary, there 
is an exponential increase in interfaces as elements are added to the equation. Citing 
Metcalfe’s Law, while ignoring disputes on its continued validity (Briscoe, Odlyzko, & 
Tilly, 2006), the number of connections a component can make with other components in 
a network equals: 


n(n - 1) (1) 

or roughly n 2 as n increases, with n being the number of nodes on the network. Because 
the systems being proposed for inclusion into the MOC are not all interfaced, the system- 
to-system and human-to-system interfaces are even more complex if not ambiguous. 
Therefore, every time a new system (node) is proposed for inclusion into the MOC SoS, 
the effects cannot be clearly recognized. 
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3 METHODOLOGY: SUBSEQUENT STEPS 


3.1 REQUIREMENTS 

Once team members had an understanding of the work that had been conducted on the 
MOC and the supporting artifacts, the focus changed to understanding the requirements 
that were driving the work. In order for the work to be seen as relevant, it must support 
traceability to the source requirements; therefore we acknowledged the need to first 
identify those source requirements. Research of program document repositories and 
discussions with key personnel has supported the absence of any validated requirements. 

Without formal validated requirements, the decision was made to trace the tasks provided 
in the OV-6c to the original source documents. The MOC CONOPS describes core 
processes that support “standardized processes and methods that are fully compatible 
with both service and joint guidance” with the goal of facilitating the sharing of 
information, coordination, and load sharing between MOCs when necessary (U.S. Fleet 
Forces Command, 2007). It specifically cites an analysis of the UJTLs as the foundation 
of the MOC core processes. This document also credited the operational architecture as 
the source used to compile the descriptions of the core processes to include “inputs, 
major players, and products.” Involvement with the MOC Architecture IPT made it clear 
that the architectures were still evolving, yet these artifacts were the foundation for the 
development of the processes that define the MOC. Review of the architectures 
published to the Department of Defense Architectural Repository System (DARS) 
revealed numerous references to draft documents as resources in their development. One 
specific example in the OV-5 Activity Model, the operational task of Prepare Plans and 
Orders (OP 5.3) cites the draft version of the Capabilities Development Document (CDD) 
for the Net-Enabled Command Capability. Further research is necessary to determine if 
there has been sufficient configuration management implemented to account for changes 
to referenced capabilities and the effect those changes may have had on the processes and 
systems developed around the originally proposed capability. 
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The absence of validated requirements and architectural views brought to question the 
inherent limitations in the accuracy of the initial analysis conducted in order to establish 
the core processes. It was recognized that numerous assumptions of validity were 
necessary in order to move forward. Although the UJTLs were accepted as the 
authoritative documents for the operational activities of war, the knowledge and 
experience of those persons who conducted the analysis of the UJTLs to develop the core 
processes is unknown. Every element of warfare has been addressed in the CONOPS and 
other artifacts, and an underlying assumption has been made that the resultant products 
are valid. 


3.2 RELATIONSHIPS 

The following paragraphs describe the team’s efforts to identify relationships between 
MOC tasks and systems. This began with a review of the published architecture views in 
DARS. Systems Architect (viewer) is the software tool used to examine the architecture 
products maintained in DARS. In addition to viewing the products, the system also 
provided background information on each of the elements, such as which documents 
were used referenced during the generation of the view. 

If the published architectures are considered to be valid, the existing depiction of required 
actions in the OV-6c can be used to establish the relationships between activities and 
systems and generate a valid Operational Activity to Systems Function Traceability 
Matrix (SV-5a). The draft SV-5a developed by the MOC working group currently exists 
in an Excel spreadsheet in the form of a matrix with 1,067 rows and 517 columns, which 
are split between three different worksheets. This matrix consists of 551,639 cells that 
are meant to identify relevant information, and the data it contains is entered and tracked 
manually. 

The limited usefulness of the draft SV-5a can also be attributed to the lack of validated 
requirements. At the time of review, the 1,067 rows in the matrix listed the required 

system functions proposed by the working group, most of which had not been derived 
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from the MOC processes. On the contrary, the list of functions appeared to have been 
developed independently of the core processes and was drawn from sources such as the 
Common Systems Function List (CSFL) and FORCEnet System Functions (FnSF). 
Some “new” system function requirements have been included by unidentified persons, 
but as they were included, they were not traced to governing documentation. In May of 
2009 the Architecture IPT augmented the efforts to identify relationships to the core 
processes. 


3.2.1 Conceptual vs. Reality 

Development of the MOC concept into reality has posed many challenges. One such 
challenge is the goal to provide the capabilities desired by the customer as quickly as 
possible. As development of the MOC concept progressed, the need to incorporate 
greater capabilities resulted in decisions to include conceptual systems that had not been 
fielded (and possibly never would be) into the design. And though this is not an 
uncommon practice in acquisition, the risk associated with doing so must be 
acknowledged. This approach has been seen frequently in the attempt to present the 
MOC concept as an achieved reality. Documents depicting Spiral builds with changing 
baselines have been signed and released, but with the inclusion of “drawing-board” 
systems and placeholders that describe future capabilities instead of achieved technology. 


3.2.2 Interoperability vs. Integration 

During the relationship phase, the discussion of multiple systems involved in single core 
processes inspired numerous discussions on requirements for information sharing or 
transfer between systems to accomplish a given task. Although the issue was detennined 
to exceed the scope of our analysis, the fact remained that these relationships would have 
to be defined. Normally accomplished in a program’s Information Support Plan (ISP), 
these relationships would be clearly delineated and each interface would require 
interoperability testing as appropriate. Research into the MOC effort revealed no such 
document. Our analysis acknowledged the inclusion of multiple systems in various core 
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processes and defaulted to the assumption that appropriate interoperability or system 
interfaces existed, whether man-to-machine or machine-to-machine. Further analysis 
will be required to detennine the extent of interoperability required in the MOC construct 
as well as data format as it affects the exchange of information. 


3.2.3 Tracing 

The actual process of tracing relationships of tasks to systems was divided among team 
members and the results were entered into the software tool chosen to assist in the 
analysis. CORE® 5.1.5 was chosen by the team to provide automation in the tracing 
process. The availability of CORE® through the NPS Virtual SE Lab allowed access by 
all members. An assessment of the capabilities of the tool determined it would provide 
the necessary functionality to accomplish our goal. An Analysis of Alternatives 
identified it as the most appropriate solution to our automation needs based on 
availability, cost and performance. 

Initial efforts attempted to trace systems to tasks beginning with the individual tasks 
drawn from the OV-6c. It quickly became apparent that redundant efforts were occurring 
because different members of the team were tracing the same core processes owing to the 
existence of a one-to-many relationship between core process and joint tasks. The team 
revised the approach by distributing the domains that were composed of the different core 
processes: Assess Effects; Operational Intel; Operational Planning; Manage 

Information; Establish Headquarters; and Execute Plans. This ensured no redundant 
activities were assigned while distributing the workload nearly evenly. 

To assist in the tracing, an Excel spreadsheet was created that consolidated the parent and 
child activities into a useable format for each of the core processes (Figure 2). This 
eliminated the need for each member to search through numerous pages of flow diagrams 
in the body of the OV-6c. Information was first entered into the spreadsheet to facilitate 
a quick transcription into CORE , thus limiting the time spent operating in the Virtual 

Systems Engineering Lab. Individual tabs in the spreadsheet corresponded to each 
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mission area domain. Each core process was then broken down into parent and child 
activities corresponding with those in the OV-6c. Columns were provided to identify the 
system allocated to accomplish the task and the spiral build the system was assigned to if 
applicable. 


1 2 3 


Spiral 10 




w 


1 EP.1.3 
i EP.1.7 
l EP.2 


Synchronize Execution Across All Domains 
Collaboratively, Rapidly Replan Operations 


I 42 EP.2.1 Approve Planning Guidance 
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i EP.2.4 
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I EP.3 

i 

l EP.3.1 
EP.3.2 
: EP.3.3 
i EP.3.4 
EP.3.5 
i EP.3.6 
i EP.3.6.1 


Develop Priority of Effort 

Shape Guidance w/Mission Partners' Concerns in Mind 

Develop the Commander's Planning Guidance 

Make Commander's Planning Guidance Visible/Accessible 

e Health Services 

Request Health Services Support 
Coordinate Health Service Allocation 
Submit Patient Movement Request 
Transmit MEDEVAC OPS Info 
Receive MEDEVAC OPS Coordination Info 
Coordinate Patient Movement 
Administratively & Clinically Validate Patient 


NCES 
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NCES 
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C2PC 


C2PC 


GCCS-M/J/I3 

GCCS-J 
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NCES 


NCES 

DCGS-N; NCES 


NCES; M3 
GCCS-M/J; NCES 


CPOF; DJC2 
CPOF; DJC2 


System not requii 


Is Shared Support 


Figure 2 - CORE® preparation 

A spreadsheet derived from the elements of the OV-6c was developed to streamline 
the capture of information and minimize the time spent transcribing date into 
CORE® while logged into the Virtual Systems Engineering Lab on the NPS 
network. 


3.2.4 CORE® Schema 


The resulting spreadsheets were transcribed into the CORE® 5.1.5 tool on the NPS 
Virtual Systems Engineering Lab. As seen in Figure 3, the Systems Engineering schema 
was selected, although the DoDAF schema was considered as an alternative. Further 
consideration for appropriate schema selection, or creation, is recommended for future 
efforts using the tool, but the schema selected was determined to be more appropriate for 
this project. 
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Figure 3 - SE Schema 

This screenshot of the SE Schema within CORE 1 * shows which elements were used 
to conduct the analysis. 


Elements in the Systems Engineering Schema that were utilized in the relationship 
tracing included Component; Document; Function; Issue; and Requirement. The first 
step in setting up the schema was to determine what information was necessary to create 
the elements within the CORE 8 project. 


3.2.5 CORE®: Requirement 

The MHQ MOC CONOPS provided the in formation necessary to derive requirements. 
The mission area descriptions in the CONOPS identified the responsibilities of each 
element and sub-element within the MOC organization. These were drawn out as 
individual requirements to which the functional requirements could be associated and 
were entered into CORE 8 as “Requirement.” As they were entered, a relationship of 
“documented by” was established with the CONOPS in order to validate the requirement. 
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3.2.6 CORE : Function 


The OV-6c provided to the team identified the necessary functions. Each process flow 
identified consisted of a string of parent and child activities. Each of these activities had 
to be accomplished in order for the core process to be completed, and it was the 
completion of these core processes that provided the capabilities necessary to accomplish 
the identified mission. These activities were designated as “Function” in CORE® and 
became the target of the functional tracing that would determine if capability gaps 
existed. As they were entered, a relationship of “decomposed by” was assigned to child 
activities in relation to the parent activity from which they were derived. This established 
the hierarchal relationship to be used for the gap analysis. If a child activity could not be 
completed, the parent activity also could not be completed. This allowed for an in-depth 
analysis that would not be apparent otherwise. 


3.2.7 CORE®: Component 

The ultimate goal of this project was to assign systems to functions in order to determine 
if the MOC could accomplish the missions assigned to it using those systems. The entire 
effort hinged on the ability to identify and assign those relationships. One barrier that 
was presented was the ability to identify systems that would become standardized in their 
use by the various fleet customers. Without that standardization, each MOC could utilize 
their solution and one basic goal of the MOC concept would remain unrealized. During 
the research of documentation, two letters signed out by the Director, Warfare Integration 
(N6F) only one year apart were discovered that were meant to accomplish that 
standardization. The first, with the subject “MARITIME HEADQUARTERS WITH 
MARITIME OPERATIONS CENTER (MHQ w/MOC) SYSTEMS REQUIREMENTS” 
provided an enclosure listing the systems that were to comprise the spiral 8 baseline 
(Director, Warfare Integration N6F, 2007). The second, with the same subject, was to be 
the update with the spiral 10 baseline (Director, Warfare Integration N6F, 2008). The 
expectation that the spiral 10 baseline would include the systems from the spiral 8 
document was not realized. The spiral 10 document only referenced the previous release 
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and showed only the newly identified MOC systems. Although the information did exist, 
the ability to obtain the official documentation was less than efficient. These highlighted 
the need to baseline system composition in a single location or, at a minimum, provide 
additional enclosures to subsequent baseline updates that show all of the systems to be 
included. 


3.3 ANALYSIS 

Upon the conclusion of establishing the relationships between the activities that 
comprised the core processes, an analysis of the tracing efforts began. The benefit of 
entering the data into an automation tool was the ability to manipulate views based on the 
level of detail desired. The overall view helped to establish a perspective of the 
undertaking at hand. There were 496 functional activities included in our analysis. 
These activities encompassed the derived actions necessary to accomplish only 44 tasks. 
With an undetermined number of tasks that would comprise the entire portfolio of 
mission requirements, the complexity of a complete analysis can be inferred. That 
knowledge should be considered when considering the method by which requirements 
will be continually assessed as the MOC concept evolves and additional systems are 
considered for inclusion. 

Automation could contribute to a true conditional consequence analysis as the complexity 
of the relationships increases according to aforementioned Metcalfe’s Law. As the 
configuration of the MOC continues to evolve, obsolete systems will be considered for 
replacement or new capabilities will be achieved with additional systems. The interfaces 
identified for each system would allow a rapid assessment of the consequences for 
removing a system, which activities are affected by that removal, and whether those 
capabilities can be achieved by the replacement system or through some other interface. 
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3.4 ARRIVING AT CONCLUSIONS 


The final phase of the team’s project was the formulation of a conclusion to the question 
of whether a MOC can complete the missions assigned based on functional capabilities 
present in the configuration of systems. The analysis did show the existence of capability 
gaps; therefore the MOC will be unable to perform the missions assigned with organic 
systems unless capability augmentation is conducted. This conclusion will be explained 
in greater detail in Sections 4 and 5. 
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4 METHODOLOGY APPLICATION AND VALIDATION 


This section summarizes efforts executed in support of the MOC traceability project 
described in Section 3. It further documents and examines the capability gaps in 
implementing MOC. The following sub-sections provide detailed findings of the analysis. 

As detailed in Section 3, well-documented systems engineering (SE) processes were not 
used in earlier studies generating MOC requirements. Lack of SE process is evident in 
the DoDAF artifact, OV-6c, as it struggled to decompose the high level MOC 
requirements into business rules and tactical functions. The following sub-sections 
describe the gaps discovered when trying to allocate the requirements to systems. 


4.1 EXECUTION OF OVERALL APPROACH 

The MOC requirements were obtained from the CONOPS, the OV-6c, and several high 
level directives. Our Capstone team applied several methods in conducting the functional 
analysis. Initially, the team identified a small pool of systems that could fulfill the six 
top-level MOC functional areas. This initial analysis was conducted utilizing a Microsoft 
Excel spreadsheet and was conducted before specific systems planned for the MOC were 
known to the team. Once the Spiral 8 and Spiral 10 systems were identified, the Capstone 
team repeated a similar Microsoft Excel analysis. The final gap analysis was conducted in 
CORE®. 


4.1.1 Section Overview 

Requirements were allocated to systems using CORE®, a systems engineering tool used 
to document, decompose and allocate requirements. The remainder of this section 
discusses the steps taken to populate the requirements into CORE®, find association to 
other requirements (if any), allocate them to systems, and identify gaps where systems 
have not been identified to satisfy a given requirement. 
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As described in Section 3, because the number of functions developed by the MOC 
Architecture IPT was so high, our capstone team had to first identify the ones that were 
traceable to requirements. Instead of the 1,067 functions listed in the SV-5a, the team 
identified and uploaded to CORE 496 tasks extracted from the OV-6c. Similarly, the 
known requirements documents, reference documents, and components were identified 
and uploaded into CORE®. 

Next, relationships between functions were identified and established in CORE®. In this 
process, some of the tasks were identified to be children, or sub-functions, of other 
functions. Identification of relationships between tasks assisted in the decomposition of 
high-level requirements to lower-level requirements that could then be allocated to 
components. 

Allocation to systems followed next. The pool of systems loaded to CORE* was derived 
from Spirals 8 and 10 of MOC System Description documents. Our Capstone team 
researched each system’s capability and allocated functions to appropriate systems. The 
following sub-sections will describe details of the systems allocation process and results 
of the gap analysis. 


4.2 REQUIREMENTS GENERATION AND ANALYSIS 

Figure 4 graphically depicts the six core processes that comprise the actions which fulfill 
the 44 functions identified in the OV-6c and were assessed by the team. The following 
paragraphs will discuss the results of the team’s assessment. 
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Figure 4 - MOC Core Processes 

This figure depicts the six core processes performed by the MOC (U.S. Fleet Forces 
Command, 2007) 

4.2.1 Assess Effects 

The MOC Architecture IPT obviously had a difficult task of defining the core processes 
because the MOC did not follow the normal DoD acquisition process or a disciplined 
systems engineering development process. Instead, existing U.S. Naval commands were 
asked to describe how to perform MOC activities. As such, the MOC functions enlisted 
by the MOC Architecture IPT were simply lists of functions each command’s capability 
needed to effectively synchronize joint maritime operations in planning, execution and 
assessment of operations. This unorthodox requirement generation method has resulted in 
several requirement overlaps and some requirement gaps. 

The first top-level function analyzed was Assess Effects. The Capstone team identified 
sixteen core processes to address the Assess Effects function. Each of these tasks was 
successfully allocated to available systems. 


4.2.2 Operational Intelligence 

Using similar method of segregation of MOC functions, our Capstone team identified 
102 activities to be associated with Operational Intelligence (OPINTEL). These 
requirements were identified to the best of our team’s understanding based on their 
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descriptions and estimates of their capability of meeting a MOC requirement. All 102 
were successfully allocated to systems. 


4.2.3 Operational Planning 

The MOC Operational View (OV-6c) our team received did not provide complete 
information on what needed to be accomplished and who should be doing it. 
Requirements for Operational Planning were relatively easier to identify as MOC is an 
operation-centered defense component. There were 112 activities identified to satisfy the 
Operational Planning requirement. One hundred eight of the activities were successfully 
allocated to systems. 


4.2.4 Manage Information 

Eighty-five activities were identified that applied to the 5 sub-processes that made up the 
core process Manage Information. The sub-processes that make up the Manage 
Information core process are Manage Requests for Operational Information, Develop IM 
Plan, Manage Battle Rhythm, Establish Collaborative Information Environment (CIE), 
and Conduct CND Operations. Most of the functions within Manage Information were 
successfully allocated to systems. Sixty-nine of the activities were successfully allocated 
to systems. 


4.2.5 Establish Headquarters 

Forty-four activities were identified for the core process of Establish Headquarters. Of 
the 44 activities, 39 were traced to systems. The Establish Headquarters core process 
was further refined to Establish HQ and Coordinate Joint Training sub-processes. Most 
of the functions under this core process were allocated to the Global Command and 
Control Systems-Maritime (GCCS-M). Descriptions of these systems are detailed in most 
of the referenced documents. 
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4.2.6 Execute Plans 


Similarly, 135 functions were identified to be associated to Execute Plans core process. 
112 of them were successfully traced to systems. Results of the gap analysis on the 
remainder are discussed in the next section. 


4.3 MOC FUNCTIONAL ANALYSIS AND ALLOCATION 

As discussed previously, an analysis was performed by the MOC project team to 
determine whether the functions required by the MOC, identified in the OV-6c, can be 
fulfilled by current and proposed systems. The MOC Spiral 8 Systems Description 
document, MOC Spiral 10 Systems Description document, and current systems not 
identified in the MOC systems documents were considered for the functional allocation 
analysis. 


Using CORE® 5.1.5, the relationship of system to function was quickly established. If 
there was no system allocated to a function, then the model would graphically depict a 
GAP component allocated to the function. This indicates that there is no system available 
that can accomplish the function and a capability gap exists. Figure 5 provides an 
example of a CORE B graphical depiction of a capability gap. The following section 
includes excerpts of the tables provided in the Appendix. These excerpts depict examples 
of the systems assigned to each of the core process activities and any gaps identified. 
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Figure 5 - Capability Gap Depicted in CORE® 

This figure illustrates a capability gap with reasoning provided as an Issue 

4.3.1 Assess Effects 

As seen in Table 8, all functions within the Assess Effects core process were allocated to 
GCCS-M. In addition, 6 of the 16 functions were also allocated to Command and 
Control PC (C2PC) and 3 were also allocated to the Air Defense System Integrator 
(ADSI). Overall, 3 functions, Determine MOEs Achieved, Determine Success or Failure 
and Determine Unintended Effects were allocated to all 3 systems, GCCS-M, C2PC and 
ADSI. Assess Battle Effects, Conduct Weapons Effectiveness Assessment and Compare 
Achieved vs. Desired Results were allocated to 2 systems, GCCS-M and C2PC. All 
remaining functions were allocated only to GCCS-M. Although GCCS-M is able to 
perform all required functions that enable a MOC to continually assess the outcome of 
operations, a command can still perform functions under the Assess Effects core process 
with C2PC and/or ADSI. This indicates possible capability overlaps. It could also 
indicate back-up capabilities to accommodate failure or heavy loading of primary 
systems. 


Table 2 - Excerpts of Table 8 Systems Allocated to Assess Effects Functions 


Functions 

Systems 

AE.1.1 

Develop Assessment Plan 

GCCS-M 

AE.1.2 

Assess Achievement of Desired Effects 

GCCS-M 

AE. 1.2.1 

Develop Combat Assessment Plan 

GCCS-M 

AE. 1.2.2 

Assess Battle Effects 

GCCS-M, C2PC 

AE. 1.2.3 

Estimate Initial Damage 

GCCS-M 
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Table 2 (continued) 


Functions 

Systems 

AE. 1.2.4 

Estimate Functional Damage 

GCCS-M 

AE. 1.2.5 

Estimate Ability to Reconstitute 

GCCS-M 

AE. 1.2.6 

Conduct Weapons Effectiveness Assessment 

GCCS-M, C2PC 

AE. 1.2.7 

Develop Process for Monitoring & Understanding 
Operational Environment 

GCCS-M 

AE. 1.2.8 

Provide Feedback on Operations 

GCCS-M 


4.3.2 Operational Intelligence 

In this section, all available systems that would help determine the critical information a 
commander requires to understand the flow of operations and to make timely and 
informed decisions were identified. Systems identified in this section would gather 
friendly, enemy, and environmental information. A total of 102 tasks were identified to 
support this core MOC process and all were allocated to one or more systems. Of these 
processes, 58 were successfully allocated to the Global Command and Control System- 
Integrated Imagery and Intelligence (GCCS-I3) and GCCS-M systems. Complimentarily, 
36 other processes were allocated to the systems Generic Area Limitation Environment 
(GALE), Joint Service Imagery Processing System (JSIPS), Distributed Common Ground 
System-Navy (DCGS-N) and Analyst Notebook. Three activities were allocated to the 
Net-Centric Enterprise Services Collaboration Tool (NCES) and Information Work Space 
(IWS), and 5 were allocated to Joint Deployable Intelligence Support System (JDISS) 
and DCGS-N. A more detailed accounting of the systems allocated to each function is 
listed in Table 9. Functions that have more than one system allocated indicated a 
possible capability overlap. Details of the gap analysis are documented in the next 
section. 


Table 3 - Excerpts of Table 9 Systems Allocated to Operational Intelligence 
Functions 


Functions 

Systems 

OI.l.l 

Review Mission for 0P1NTEL Needs 

GCCS-M, GCCS-I3 

01.1.2 

Develop PIRs 

GCCS-M, GCCS-I3 

01.1.2.1 

Analyze OPLAN, COAs and ECOAs by Phases 

GCCS-M, GCCS-I3 

01.1.2.2 

Collate Intelligence Required for Operational l&W 

GCCS-M, GCCS-I3 
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Table 3 (continued) 


Functions 

Systems 

01.1.2.3 

Distill Intelligence Requirements 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.2.4 

Rank, Prioritize Intelligence Requirements 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.2.5 

Determine Intelligence Vital to Mission by Phase of Op 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.3 

Identify Intelligence Knowledge Gaps 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.4 

Generate RFIs 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.5 

Develop Draft Collection Plan 

GCCS-M, GCCS-I3 


4.3.3 Operational Planning 

Our team allocated Operational Planning tasks to systems that enable a commander to 
effectively plan for and execute operations, ensure that the employment of forces is 
linked to objectives, and integrate naval operations seamlessly with the actions of a joint 
force. The Operational Planning core process was decomposed to 112 activities, 108 
were successfully allocated among 25 systems as identified in Table 10. A large number 
of these tasks were to be accomplished by utilizing Global Combat Support System - 
Combatant Commander (GCSS-CC/JTF) and Collaborative Force Analysis, Sustainment, 
and Transportation (CFAST). Figure 6 is a graphical depiction of the number of tasks 
assigned to each of the systems identified for use in the execution of Operational 
Planning. 

The functions that did not have any systems allocated are: 

• Determine Recommended CCIRs 

• Develop Appropriate Annexes, Appendixes & Tabs 

• Reconcile Plans and Orders 

• Back Brief & Crosswalk Orders 


From the analysis conducted by the MOC project team, there does not appear to be a 
known system that has the capability to fulfill these functions. These are shown as 
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Capability Gap in the table. Functions that had more than one system allocated to it 
indicated a possible capability overlap. 



Figure 6 - Operational Planning Tasks allocated to Systems 

This figure details the number of activities within the core process assigned to each 
of the systems determined to provide the needed capability. 


Table 4 - Excerpts of Table 10 Systems Allocated to Operational Planning Functions 


Functions 

Systems 

OPP.1.3 

Approve/Modify Mission Statement 

JADOCS, JCRE 

OPP.1.8 

Approve/Modify COA 

JCRE, ISPAN 

OPP.1.11 

Approve Plans/Orders 

JCRE 

OPP.1.1 

Conduct Operational Mission Analysis 

MIPS, DCGS 

OPP.1.1.1 

Analyze Higher Commander's Mission 

MIPS, DCGS 

OPP.1.1.2 

Develop Objectives 

MIPS, DCGS 

OPP. 1.4.2 

Determine Recommended CCIRs 

Capability Gap 

OPP.1.10.3 

Develop Appropriate Annexes, Appendixes & Tabs 

Capability Gap 

OPP.1.10.6 

Reconcile Plans and Orders 

Capability Gap 

OPP.1.10.7 

Back Brief & Crosswalk Orders 

Capability Gap 
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4.3.4 Manage Information 

According to the MOC OV-6c, “Information management, possibly by artificial as well 
as human agents, would ensure that decision makers have ready access to the information 
they want and need while minimizing the risk of information overload.” To this end, 6 
sub-processes were identified and further refined into 85 tasks. Our team successfully 
allocated these tasks among 30 systems. As shown in Figure 7, the Consolidated Afloat 
Networks and Enterprise Services (CANES) accomplishes 10 of these tasks; however, it 
is clear that diverse information gathering, filtering or analysis systems would have to be 
deployed in order to accomplish all required tasks under Manage Information. 



Figure 7 - Number of Manage Information Activities allocated to Systems 

This figure details the number of activities within the core process assigned to each 
of the systems determined to provide the needed capability. 


The Manage Information core process was decomposed to 84 activities of which 66 were 
allocated to one or more systems. The system(s) allocated to each function can be found 
in Table 11. 
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The functions that did not have any systems allocated are listed here and assigned 
“Capability Gap” in the systems column in Table 11: 

• Ensure Authorized Entities & Information Used 

• Adapt info Sharing to Accommodate Evolving Needs 

• Manage Information Management Cell 

• Manage Workgroup Managers (embedded/shared) 

• Manage Electronic File Plan 

• Manage Suspense Control 

• Provide Component IM Cell Services 

• Develop Data/Information 

• Determine Information Pedigree 

• Maintain Information Pedigree 

• Establish Digital Rules of Protocol 

• Identify Subscription 

• Request Subscription 

• Evaluate Subscribed Data/Information 

• Update Subscription 

• Formulate Discoveiy Search 

• Coordinate IMP 

• Provide Computer Network Defense Services 

From the analysis done by the MOC project team, there does not appear to be a known 
system that has the capability to fulfill these functions. These are shown as Capability 
Gap in the table. Functions that had more than one system allocated indicated a possible 
capability overlap. 


Table 5 - Excerpt of Table 11 Systems Allocated to Manage Information Functions 


Functions 

Systems 

MI. 1.1 

Ensure Authorized Entities & Information Used 

Capability Gap 
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Table 5 (continued) 


Functions 

Systems 

MI. 1.2 

Adapt info Sharing to Accommodate Evolving Needs 

Capability Gap 

MI. 1.3 

Manage Information Management Cell 

Capability Gap 

MI. 1.3.1 

Manage Workgroup Managers (embedded/shared) 

Capability Gap 

MI.1.3.2 

Provide Overall Info-Related Admin Support 

MSRT 

MI.1.3.3 

Manage Electronic File Plan 

Capability Gap 

MI.1.3.4 

Manage Messaging Services 

TBMCS, DJC2 

MI.1.3.5 

Manage Suspense Control 

Capability Gap 

MI.1.3.6 

Provide Component IM Cell Services 

Capability Gap 

MI. 1.4 

Provide/Publish Data/Information to Net-Centric 

Environment 

CNDE, CANES 


4.3.5 Establish Headquarters 

The Establish Headquarters core process was decomposed to 44 activities, 43 of which 
were allocated to at least one or more systems. The system(s) allocated to each function 
can be found in Table 12. The majority of the activities could be accomplished by the 
GCCS systems. Other systems, such as the Global Combat Support System (GCSS) and 
Deployable Joint Command and Control (DJC2), also fulfilled some of the activities 
allocated to the GCCS systems. 

The activity that did not have any systems allocated is: 

• Sub Component Interagency 

It was determined that this activity would not be performed by MHQ w/MOC. This is 
shown as a Capability Gap in the table. Activities that had more than one system 
allocated to it indicated a possible capability overlap. 


Table 6 - Excerpts of Table 12 Systems Allocated to Establish Headquarters 
Functions 


Functions 

Systems 

EHQ.1.1 

Establish Appropriate Organizational Relationships 

GCCS-M 

EHQ.1.6 

Connect & Interface with Non-DoD Organizations 

GCCS-M 

EHQ.1.7 

Establish Role-Based Knowledge Framework 

GCCS-M 

EHQ.1.8 

Form Distributed Teams/COIs/CofP 

GCCS-M, GCSS 
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Table 6 (continued) 


Functions 

Systems 

EHQ.1.8.1 

Access Subject Matter Expert & Essential 

Information 

GCCS-M, GCSS 

EHQ. 1.8.2 

Identify COI/CofP 

GCCS-M 

EHQ. 1.8.3 

Establish COI/CofP 

GCCS-M 

EHQ. 1.8.4 

Develop COI/CofP Charter 

GCCS-M 

EHQ.1.8.5 

Prioritize Information Sharing Capabilities 

GCCS-M, GCSS 

EHQ. 1.11 

Sub Component Interagency 

Capability Gap 


4.3.6 Execute Plans 

The Execute Plans core process was decomposed to 135 activities; of which 119 were 
allocated to one or more systems. The system(s) allocated to each activity can be found in 
Table 13. 

The activities that did not have any systems allocated are: 

• Administratively & Clinically Validate Patient 

• Provide Patient Attendants & Movement Items 

• Move Patient 

• Conduct Patient Evacuation 

• Provide Headquarters Personnel & Infrastructure 

• Provide Augmentation 

• Provide for Personnel Sendees 

• Process JIP TL/JIP CL/Asset Appointment 

• Provide Tailored Space Training 

• Develop/Maintain Logistics Base in JO A 

• Predict Repair/Maintenance Requirements 

• Sense Repair/Maintenance Requirements 

• Configure Netted Sensor Grid 

• Task Sensor 

• Conduct Dynamic Cross-Cuing of Sensor Data 

• Provide Sensor Tip-Off 
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From the analysis done by the MOC project team, there does not appear to be a known 
system that has the capability to fulfill these functions. This is shown as Capability Gap 
in the table. Activities that had more than one system allocated to it indicated a possible 
capability overlap. 


Table 7 - Excerpts of Table 13 Systems Allocated to Execute Plans Functions 


Functions 

Systems 

EP.3.6.1 

Administratively & Clinically Validate Patient 

Capability Gap 

EP.3.6.6 

Provide Patient Attendants & Movement Items 

Capability Gap 

EP.3.6.7 

Move Patient 

Capability Gap 

EP.3.7 

Conduct Patient Evacuation 

Capability Gap 

EP.5.4 

Provide Headquarters Personnel & Infrastructure 

Capability Gap 

EP.5.4.3 

Provide Augmentation 

Capability Gap 

EP.5.7 

Provide for Personnel Services 

Capability Gap 

EP.6.15 

Process JIP TL/JIP CL/Asset Appointment 

Capability Gap 

EP.7.5 

Provide Tailored Space Training 

Capability Gap 

EP.9.2 

Develop/Maintain Logistics Base in JOA 

Capability Gap 

EP.9.8.1 

Predict Repair/Maintenance Requirements 

Capability Gap 

EP.9.8.2 

Sense Repair/Maintenance Requirements 

Capability Gap 

EP.10.2 

Configure Netted Sensor Grid 

Capability Gap 

EP.10.3 

Task Sensor 

Capability Gap 

EP.10.4.3 

Conduct Dynamic Cross-Cuing of Sensor Data 

Capability Gap 

EP.10.4.4 

Provide Sensor Tip-Off 

Capability Gap 


4.4 VERIFICATION AND VALIDATION 

Once all the relevant data (documents, requirements, functions, systems, etc.) had been 
compiled, the relationships were established as described in Section 4.3. The next phase 
of the project involved populating the model in CORE 8 5.1.5. The CORE® software uses 
a model-based systems engineering (MBSE) approach for system and architecture 
development. For the purpose of this project, the CORE 8 software was used establish 
traceability from the MOC CONOPS and other documents to the functions and systems. 
The ultimate goal was to generate graphical views to allow the users to easily identify the 
MOC capability gaps and possible overlaps. 
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The Systems Engineering (SE) schema in CORE® was used to build the model. The SE 
schema provided the classes, relationships, and attributes necessary to establish the 
traceability for the MOC project. Figure 8 provides an overview of the classes and 
relationships that can be established. Not all of the available class relationships were 
included in the figure for clarity. Additional classes were used in the MOC project, 
including Issue, Document, and Category. 
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relationships exist to capture issues, risks, test 
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Figure 8 - Overview of Class Relationships Established in CORE® 

This diagram reflects the heart of the systems engineering schema. Additional 
classes and relationships exist to capture issues, risks, test & evaluation material, 
and much more. (Vitech Corporation, 2005) 


4.4.1 Populating CORE® 

The MOC CONOPS and DODAF artifacts (SV-4a, SV-5a, SV-8, and OV-6c) were the 
primary sources of data for populating the CORE" model. Populating the model was 
expedited with the aid of the Element Extractor feature in CORE". The Element 
Extractor allows the user to quickly populate the CORE" model from existing 
documents. The relevant documents were first loaded to the Element Extractor. The user 
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then selected text from the document and chose a field in the Element Definition window 
to be populated. Attributes not available in the documents had to be entered manually. 
Figure 9 shows the Element Extractor being used to extract text from the MOC Spiral 10 
Systems Description document. 



Figure 9 - CORE® Element Extractor 

Captures relevant information from references to associate with individual elements 

Data was extracted to elements of different classes. As shown in Figure 10, only 7 of the 
SE schema classes were used for the MOC project. The Category class contains Assess, 
Plan, and Execute elements to which all the requirements are categorized. The 
Component class contains the systems elements. The Document class contains the 
document elements. The Function class contains the functions the MOC is required to 
perform. The Issue class contains the issue elements, which are allocated to functions if 
an issue requiring future action is identified. The Item class contains the UJTL task 
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elements. The Requirement class contains the requirement elements drawn from 
governing documentation. 
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Figure 10 - CORE® SE Classes 


4.4.2 Establishing Relationships 

Relationships can be established between elements of different classes and elements of 
the same class. This can be accomplished by selecting the appropriate type of relationship 
in the Relationships field as shown in Figure 11. 
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Figure 11 - Relationships 

This figure illustrates relationships between elements of different classes or of the 
same class. 


Figure 12 shows some of the key types of relationships allowed in the CORE® SE 
schema. Additional relationship types not shown in the figure, such as generate and 
generated by, were used to tie issues to functions. If a function element does not have a 
component allocated, an Issue element is generated. Not all of the relationships were used 
for the MOC project. 
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Figure 12 - Key SE Relationships 

This diagram reflects the heart of the systems engineering schema. (Vitech 
Corporation, 2007) 
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For the MOC project, the following relationships were established: 

• Category categorizes Requirement 

• Requirement refines Requirement 

• Function allocated to Component 

• Function (sub-function) decomposes Function 

• Function generates Issue 

• Document documents Function, Requirement, Component 

Relationships always exist in both directions; however, only one relationship needs to be 
established by the user. Once a relationship is established from one element, CORE® will 
automatically establish the relationship from the other element. For example, if an 
allocated to relationship is established from the Function element to the Component 
element, CORE 1 ' will establish a performs relationship from the Component element to 
the Function element. 


4.4.3 Generating Views 

The effectiveness of using CORE 8 for the MOC project is realized by the different views 
that can be generated. While there are many views and DODAF artifacts that can be 
generated from CORE®, the MOC project focuses primarily on two, the Element 
Relationship (ER) diagrams and the hierarchy diagrams. The ER diagram for an element 
displays all the direct relationships linked to that element. Two examples of ER diagrams 
are shown in Figure 13 and Figure 14. Figure 13 shows that the Falconview system 
performs Plan Evacuation Route and Develop Base Paragraphs for Operation Plans & 
Orders functions. Figure 14 shows that the Provide In-transit Patient Visibility function is 
allocated to four systems, possibly indicating capability overlaps. It also decomposes the 
Coordinate Patient Movement function, indicating that it is a child activity to that 
function. 
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Figure 13 - Element Relationship Diagram of the Falconview Component 
This diagram depicts the activities to which the Falconview system is allocated 
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Figure 14 - Element Relationship Diagram 

This diagram identifies which systems have been allocated to accomplish the 
assigned activity. 
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Customizable hierarchy diagrams can also be generated, showing traceability from high 
level functions to individual systems. Figure 15 shows a partial view of the hierarchy 
diagram for the Assess Effects core process. As shown in the figure, the Assess Effects 
core process was decomposed to sub-functions by two levels. Those sub-functions were 
allocated to one or more systems. The types of relationships are also displayed. 
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Figure 15 - Partial View of traceability 
This diagram illustrates the traceability provided by CORE® 

4.4.4 Validation 

The views generated by CORE® graphically display the MOC capability gaps and 
overlaps. If the determination was made that no system can fulfill a function, a GAP 
component element was allocated to the function. In Figure 16, the hierarchy diagram 
shows a GAP component allocated to the function. In addition to the GAP component, an 
Issue element was generated, identifying a possible issue with the function. If multiple 
systems were allocated to a function, as shown in Figure 17, then a possible capability 
overlap was indicated. 
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Figure 16 - Capability Gaps in the CORE® Model 
This figure illustrates a capability gap with reasoning assigned as an Issue 



Figure 17 - Capability Overlaps in the CORE® Model 
This illustrates multiple systems assigned to a single activity 


Modeling with requirements software allowed for quick identification of gaps and 
traceability to core processes. As new systems become available to fill those gaps the 
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model can be updated and the effects of those changes easily identified. Additionally, 
analysis of the revised model will identify capability overlaps. 

4.4.5 Challenges of Using CORE® 

While the CORE software provided the traceability necessary for the MOC project, it is 
not without its challenges, and there were several encountered when using CORE 8 for 
this project. Since none of the team members were familiar with the software, there was a 
steep learning curve involved. This issue was overcome by completing the CORE" 8 
AutoLink guided tour to gain familiarity with CORE 8 MBSE approach. Since the 
capstone project was time bounded, the extra effort expended to become familiar with the 
software put a strain on the project. 

Limited access to CORE 8 also posed a challenge. The software was only available 
through the NPS Virtual SE lab, limiting access to those with World Wide Web access. 
The software does not have the capability for real-time collaboration with multiple users, 
slowing the progress of populating the model. Only one user could work on the data fde 
at a given time. A situation involving the licensing of CORE 8 made the software 
inaccessible for 14 days at the beginning of the third quarter of the Capstone project. 
During that time, work continued utilizing Microsoft Excel to establish the relationships. 
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5 SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS 


5.1 SUMMARY 

The goal of this project was to identify and implement a methodology for conducting an 
analysis of the operational capabilities of the Maritime Operations Centers (MOCs) based 
on assigned baseline systems in order to determine if the capabilities present would be 
sufficient to execute the mission assigned successfully. The methodology selected 
involved the use of requirements analysis software for modeling and analysis of data 
extracted from MOC documentation obtained from various sources, with emphasis on 
traceability to requirements. The analysis was completed and, based on the information 
available, a conclusion was reached that gaps exist in the functional capabilities of the 
MOC; therefore preventing the ability to successfully accomplish all assigned missions. 


5.2 CONCLUSIONS 

As stated in the summary, it was determined that several capability gaps exist if only the 
currently planned systems are available in the MOC. The systems assessed were 
identified in the Spiral 8 and Spiral 10 baseline memoranda released by the office of the 
Director for Warfare Integration (N6F). Additional systems were being identified for the 
Spiral 12 build concurrently with this analysis, but a definitive list of systems was not 
available for inclusion in this analysis. 


5.2.1 Requirements 

Requirements traceability was the foundation of the analysis conducted. However, 
because the available requirements for the MOC were inconsistent in places and were not 
validated, the analysis of capabilities was limited. The requirements to which system 
capabilities were compared were drawn from governing documentation, but were 
partially “inferred” by the project team. This was possible because involvement with 
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various MOC working groups and IPTs allowed team members to become familiar with 
the MOC development efforts that had occurred prior to commencing the project. Some 
supporting documentation was available, but configuration management appeared not to 
have been implemented in most cases. No fonnal documentation of requirements has 
been produced (as confirmed by the SPA WAR Technical Authority department) and 
many of the documents used to create the supporting architecture views have been drafts. 
It is unclear if the draft documents can be considered definitive or whether there are 
changes that have not yet been reflected in them. At the time this analysis was 
completed, neither updated versions of requirements documents nor architecture 
descriptions have been located. 


5.2.2 Gaps 

Of the six core processes that comprise the MOC functional mission areas (Assess 
Effects, Operational Intelligence, Operational Planning, Manage Information, Establish 
HQ, and Execute Plans), two were assessed to be fully-mission capable using current and 
proposed systems: Assess Effects and Operational Intelligence. The remaining four had 
a total of 37 gaps in the required capabilities. In some cases, the term “gap” could imply 
that insufficient information was available to determine which system should be assigned 
to accomplish the activity; therefore it was not possible to determine if the required 
capability existed. Other instances were attributed to the appropriateness of the level in 
the chain of command associated with the activity descriptions. Some functions appeared 
to be tactical in nature and the team concluded it would be inappropriate for a command 
and control organization to execute them. Each of these situations resulted in assignment 
as a “potential gap.” In cases where team members determined that none of the systems 
present were capable of completing the required tasks, a “true gap” resulted. 


A limitation of this study was the team’s lack of hands-on experience with some of the 
relevant systems. The number of potential gaps identified in this analysis illustrates the 
need for subject matter expert involvement. The assignment of systems in this analysis 
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was based on available system descriptions and the individual’s interpretation of each 
activity that comprised the core processes. Descriptions of systems were taken at face 
value without questioning whether they were optimistic or not. Experts more familiar 
with the proposed systems might find more gaps than those identified by the team. They 
might also be able to reclassify potential gaps as true gaps. Despite this limitation, the 
methodology applied by the team is sound and will facilitate future efforts. 


5.3 RECOMMENDATIONS 


5.3.1 Requirements 

The most important recommendation generated as a result of our project is for the Navy 
to review and refine the MOC requirements and validate a formal requirements 
document. Requirements are the cornerstone of the systems engineering process (Buede, 
2000). The success of any efforts in the development of an acquisition program hinges 
on requirements. It is impossible to detennine if the appropriate capabilities are present 
if requirements that define the functionality to be achieved are incomplete or inconsistent. 


5.3.2 Use of Software 

A significant recommendation for a program development of this size is to incorporate 
the use of requirements software. During the development of the MOC concept, the 
number of functions being considered as relevant or necessary by the working group 
exceeds 1,000 and continues to grow. The use of spreadsheets to capture and analyze a 
collection of this magnitude is inefficient and contributes to human error when 
implementing practices such as configuration management, traceability, and the 
determination of effects caused by changing the elements within the system. The ability 
to establish relationships between each element and identify traceability to requirements 
ensures the appropriate functionality is maintained and the effects of changing system 
components can be identified and mitigated. The subject of interoperability was briefly 
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discussed in this report, but due to the complexity of system interfaces it was not 
incorporated into the analysis. These interfaces can also be identified and established 
with the help of the automation software. This will ensure interoperability is taken into 
consideration and the effects identified prior to incorporating changes to system 
composition. 


5.3.3 Use of DoDAF Schema 

Utilizing a modified approach to the analysis could provide the desired gap analysis as 
well as additional benefits. The use of the DoDAF schema would provide a more 
suitable foundation for creating a detailed information architecture and a functional 
model of the MOC network. The effort would still utilize the tasks that comprise the 
UJTLs, mapping them to operational activities and subsequently establishing 
relationships to functions and systems. Identification of the relationships between the 
activities and the MOC organizational entities responsible for each action would 
complete the information flow model. Analysis of this model would also provide the 
ability to detennine any shortfalls in the necessary functionality. 


5.3.4 Incorporation into Spiral 12 

The final recommendation is to incorporate this methodology into the current spiral (12) 
development of the MOC. Doing so would provide visibility of potential shortfalls in the 
work conducted to date while providing a structured approach to future development 
efforts. Validation of requirements will prevent extraneous effort while helping to 
provide focus in the MOC development where needed. 
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APPENDIX A 

DETAILED LISTS OF SYSTEMS SYSTEM ASSIGNMENTS 


The tables below identify functional task identifiers, short descriptors, systems assigned, 
and gaps where system assignment was not possible. 


Table 8 - Systems Allocated to Assess Effects Functions 


Functions 

Systems 

AE.1.1 

Develop Assessment Plan 

GCCS-M 

AE.1.2 

Assess Achievement of Desired Effects 

GCCS-M 

AE. 1.2.1 

Develop Combat Assessment Plan 

GCCS-M 

AE. 1.2.2 

Assess Battle Effects 

GCCS-M, C2PC 

AE. 1.2.3 

Estimate Initial Damage 

GCCS-M 

AE. 1.2.4 

Estimate Functional Damage 

GCCS-M 

AE. 1.2.5 

Estimate Ability to Reconstitute 

GCCS-M 

AE. 1.2.6 

Conduct Weapons Effectiveness Assessment 

GCCS-M, C2PC 

AE. 1.2.7 

Develop Process for Monitoring & Understanding 
Operational Environment 

GCCS-M 

AE. 1.2.8 

Provide Feedback on Operations 

GCCS-M 

AE.1.3 

Compare Achieved vs Desired Results 

GCCS-M, C2PC 

AE. 1.4 

Determine MOEs Achieved 

GCCS-M, ADSI, C2PC 

AE.1.7 

Determine Success or Failure 

GCCS-M, ADSI, C2PC 

AE.1.8 

Aggregate Effects Assessment 

GCCS-M 

AE.1.5 

Determine Unintended Effects 

GCCS-M, ADSI, C2PC 

AE.1.6 

Identify and Assess Implications of Unintended Effects 

GCCS-M 


Table 9 - Systems Allocated to Operational Intelligence Functions 


Functions 

Systems 

OI.l.l 

Review Mission for 0P1NTEL Needs 

GCCS-M, GCCS-I3 

01.1.2 

Develop PIRs 

GCCS-M, GCCS-I3 

01.1.2.1 

Analyze OPLAN, COAs and ECOAs by Phases 

GCCS-M, GCCS-I3 

01.1.2.2 

Collate Intelligence Required for Operational I&W 

GCCS-M, GCCS-I3 

01.1.2.3 

Distill Intelligence Requirements 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.2.4 

Rank, Prioritize Intelligence Requirements 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.2.5 

Determine Intelligence Vital to Mission by Phase of Op 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.3 

Identify Intelligence Knowledge Gaps 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.4 

Generate RFIs 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.5 

Develop Draft Collection Plan 

GCCS-M, GCCS-I3 

01.1.5.1 

Manage Collection, Intelligence Requirements 

GCCS-M, GCCS-I3 

01.1.5.1.1 

Identify Collection Requirements 

GCCS-M, GCCS-I3 

01.1.5.1.2 

Validate Collection Requirement 

GCCS-M, GCCS-I3 
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Table 9 - Systems Allocated to Operational Intelligence Functions (continued) 


Functions 

Systems 

01.1.5.1.3 

Prioritize & Integrate Collection Requirements 

GCCS-M, GCCS-I3 

01.1.5.1.4 

Forecast Available Collection Assets 

GCCS-M, GCCS-I3 

01.1.5.1.5 

Forward CR to Next Higher Echelon 

GCCS-M, GCCS-I3 

01.1.5.4 

Synchronize ISR with Operations 

GCCS-M, GCCS-I3 

01.1.5.9 

Visualize ISR Coverage of the Operational Environment 

GCCS-M, GCCS-I3 

01.1.5.2 

Provide Collection Strategy 

GCCS-M, GCCS-I3 

01.1.5.2.1 

Establish Intelligence Collection Deadlines 

GCCS-M, GCCS-I3 

01.1.5.2.2 

Develop Collection Strategy 

GCCS-M, GCCS-I3 

01.1.5.2.3 

Determine Friendly ISR Forces/Capability (Organic) 

GCCS-M, GCCS-I3 

01.1.5.2.4 

Prioritize ISR Options 

GCCS-M, GCCS-I3 

01.1.5.2.5 

Select ISR Option 

GCCS-M, GCCS-I3 

01.1.5.2.6 

Aggregate Elements of Collection Strategy 

GCCS-M, GCCS-I3 

01.1.5.3 

Provide Draft ISR Synchronization Matrix 

GCCS-M, GCCS-I3 

01.1.5.5 

Finalize ISR Synchronization Matrix 

GCCS-M, GCCS-I3 

01.1.5.6 

Develop Draft Collection Plan 

GCCS-M, GCCS-I3 

01.1.5.6.1 

Update NAIs & Event Template 

GCCS-M, GCCS-I3 

01.1.5.6.2 

Confirm Asset/Sensor Availability 

GCCS-M, GCCS-I3 

01.1.5.6.3 

Update Environmental Information 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.5.6.4 

Refine/Revise Multi-INT Collection Plan 

GCCS-M, GCCS-I3 

01.1.5.6.5 

Generate Asset/Sensor/Placement/Route 

GCCS-M, GCCS-I3 

01.1.5.6.6 

Apply Airspace/Waterspace Management Procedures 

GCCS-M, GCCS-I3 

01.1.5.6.7 

Aggregate Elements of Collection Plan 

GCCS-M, GCCS-I3 

01.1.5.8 

Approve Collection Plan 

NCES; IWS 

01.1.5.7 

Coordinate Collection Plan 

GCCS-M, GCCS-I3 

01.1.6 

Process/Exploit BA/ISR Data 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.6.1 

Interpret Sensor Data 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.6.2 

Place Raw Data into Context 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.6.3 

Collate BA/ISR Data 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.6.4 

Correlate BA/ISR Data 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.6.5 

Fuse ISR Data 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.7 

Process & Exploit Collected Information 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.7.1 

Process Operational Environment Information 
Distributively 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.7.2 

Integrate Operational Environment Awareness 
Information 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.7.3 

Evaluate Operational Environment Information 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.7.4 

Interpret Operational Environment Information 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.7.5 

Fuse Information 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 
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Table 9 - Systems Allocated to Operational Intelligence Functions (continued) 


Functions 

Systems 

01.1.7.6 

ShareFused Information 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.8 

Analyze Operational Environment Information 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.9 

Update IPOE 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.1.10 

Conduct Predictive Analysis 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.1 

Define the Environment 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.1.1 

Identify Limits of Component Commander's Area of 
Operations 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.1.2 

Determine Significant Characteristics of Operational 

Area 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.1.3 

Establish Limits of Force's Areas of Interest 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.1.4 

Determine Full Spectrum of Force's Environment 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.1.5 

Determine Environment Detail Required 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.2 

Analyze the Environment 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.2.1 

Analyze Military Aspects of Each Dimension 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.2.2 

Evaluate Effects of Each Environment Dimension on 
Military Operations 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.2.3 

Evaluate Existing Databases & Identify Intel Gaps & 
Priorities 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.2.4 

Collect Material & Intelligence Required 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.2.5 

Confirm Area/Country Studies 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.3 

Analyze Commander Intent & Guidance 

GCCS-M, GCCS-I3 

01.2.4 

Analyze CCIR 

GCCS-M, GCCS-I3 

01.2.5 

Evaluate the Adversary (Phase 1) 

GCCS-M, GCCS-I3 

01.2.5.1 

Identify Adversary Centers of Gravity 

GCCS-M, GCCS-I3 

01.2.5.2 

Identify Adversary Objectives & Desired End State 

GCCS-M, GCCS-I3 

01.2.5.3 

Analyze Centers of Gravity (Phase 1) 

GCCS-M, GCCS-I3 

01.2.5.4 

Update or Create Adversary Models (Phase 1) 

GCCS-M, GCCS-I3 

01.2.5.5 

Identify Adversary Courses of Action 

GCCS-M, GCCS-I3 

01.2.5.6 

Determine Current Adversary Situation 

GCCS-M, GCCS-I3 

01.2.5.7 

Determine What I&W Would Point Toward Likely 
Adversary COA 

GCCS-M, GCCS-I3 

01.2.5.8 

Identify Adversary Capabilities 

GCCS-M, GCCS-I3 

01.2.5.9 

Update Adversary Patterns of Behavior 

GCCS-M, GCCS-I3 

01.2.6 

Develop Each Adversary COA 

GCCS-M, GCCS-I3 

01.2.6.1 

Select Adversary Model Representative of Considered 
Military Ops 

GCCS-M, GCCS-I3 

01.2.6.2 

Overlay Doctrinal Template on the MCOO 

GCCS-M, GCCS-I3 

01.2.6.3 

Adjust Dispositions to Account for Environment Effects 

GCCS-M, GCCS-I3 
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Table 9 - Systems Allocated to Operational Intelligence Functions (continued) 


Functions 

Systems 

01.2.6.4 

Depict Location & Activities of all HVTs in Adversary 
Model 

GCCS-M, GCCS-I3 

01.2.6.5 

Analyze& Wargame Adversary's Likely Scheme of 
Maneuver 

GCCS-M, GCCS-I3 

01.2.6.6 

Refine & Re-evaluate HVTs 

GCCS-M, GCCS-I3 

01.2.6.7 

Designate Target Areas of Interest (TAIs) 

GCCS-M, GCCS-I3 

01.2.7 

Evaluate & Prioritize Each Adversary COA 

GCCS-M, GCCS-I3 

01.2.7.1 

Identify Adversary COA Strengths & Weaknesses, 

COGs & Decisive Points 

GCCS-M, GCCS-I3 

01.2.7.2 

Evaluate How Well Adversary COA Meets Established 
Criteria 

GCCS-M, GCCS-I3 

01.2.7.3 

Evaluate How Well Adversary COA Takes Advantage 
of Environment 

GCCS-M, GCCS-I3 

01.2.7.4 

Determine Which COA Offers Greatest Advantage & 
Minimal Risk 

GCCS-M, GCCS-I3 

01.2.7.5 

Consider Adversary May Select Other COA 

GCCS-M, GCCS-I3 

01.2.7.6 

Analyze Adversary Activity to Determine if a COA 
Selected 

GCCS-M, GCCS-I3 

01.2.7.7 

Identify Adversary Preparations 

GCCS-M, GCCS-I3 

01.2.8 

Identify Initial Collection Requirements 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.2.9 

Prepare & Submit IPOE Products 

GALE, JSIPS, Analyst 

Notebook, DCGS-N 

01.3.1 

Develop Procedures for RFI Submission 

NCES; IWS 

01.3.2 

Develop Feedback Mechanism 

NCES; IWS 

01.3.3 

Validate RFI 

JDISS, DCGS-N 

01.3.4 

Submit RFI to HHQ 

JDISS, DCGS-N 

01.3.5 

Answer RFI 

JDISS, DCGS-N 

01.3.6 

Track RFIs 

JDISS, DCGS-N 

01.3.7 

Report RFI Status 

JDISS, DCGS-N 


Table 10 - Systems Allocated to Operational Planning Functions 


Functions 

Systems 

OPP.1.3 

Approve/Modify Mission Statement 

JADOCS, JCRE 

OPP.1.8 

Approve/Modify COA 

JCRE, ISPAN 

OPP.1.11 

Approve Plans/Orders 

JCRE 

OPP.1.1 

Conduct Operational Mission Analysis 

MIPS, DCGS 

OPP.1.1.1 

Analyze Higher Commander's Mission 

MIPS, DCGS 

OPP. 1.1.2 

Develop Objectives 

MIPS, DCGS 

OPP.1.1.3 

Determine Specified, Implied, Essential Tasks 

MIPS, DCGS 

OPP. 1.1.4 

State the Purpose 

MIPS, DCGS 

OPP.1.1.5 

Identify Externally Imposed Limitations 

MIPS, DCGS 

OPP.1.1.6 

Analyze Available Forces and Assets 

MIPS, DCGS 

OPP.1.1.7 

Determine Critical Factors, COGs, & Decisive Points 

IWS, VISION 

OPP.1.1.8 

Develop Planning Assumptions 

MIPS, DCGS 

OPP.1.1.9 

Conduct Initial Risk Assessment 

MIPS, DCGS 

OPP.1.1.10 

Develop Proposed Mission Statement 

MIPS, DCGS 
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Table 10 - Systems Allocated to Operational Planning Functions (continued) 


Functions 

Systems 

OPP.1.1.11 

Prepare Mission Analysis Brief 

IWS, VISION 

OPP.1.4 

Develop CCIRs 

MIPS, DCGS 

OPP. 1.4.1 

Develop Initial CCIRs 

JADOCS 

OPP. 1.4.2 

Determine Recommended CCIRs 

Capability Gap 

OPP. 1.4.3 

Approve CCIRs 

JADOCS 

OPP. 1.7 

Develop Courses of Action 

JADOCS, GIANT 

OPP. 1.7.1 

Conduct Pre-COA Development Analysis 

MIPS, DCGS 

OPP.1.7.2 

Develop Courses of Action 

JADOCS, GIANT 

OPP.1.7.3 

Analyze Courses of Action 

JADOCS, GIANT 

OPP.1.7.4 

Refine Courses of Action 

JADOCS, GIANT 

OPP.1.7.5 

Perform COA Comparison 

JADOCS, GIANT 

OPP.1.7.6 

Develop COA Decision Brief 

NCES 

OPP. 1.7.7 

Refine IPOE Based on COA Comparison 

JADOCS, GIANT 

OPP. 1.9 

Transition to Future Operational Planning 

JADOCS 

OPP.1.10 

Prepare Plans/Orders 

JSIPS, CPOF 

OPP. 1.10.1 

Plan for Actions & Resources to Achieve Desired 
Effects 

GCCS-I3 

OPP.1.10.2 

Develop Base Paragraphs for Operation Plans & 

Orders 

FalconView, GCCS-I3 

OPP.1.10.3 

Develop Appropriate Annexes, Appendixes & Tabs 

Capability Gap 

OPP.1.10.4 

Confirm Time-Phased Force & Deployment Data 
(TPFDD) 

GCCS-I3 

OPP.1.10.5 

Assess Risk on Plans/Orders 

DRRS 

OPP.1.10.6 

Reconcile Plans and Orders 

Capability Gap 

OPP.1.10.7 

Back Brief & Crosswalk Orders 

Capability Gap 

OPP.1.10.8 

Coordinate Plans & Tasking with other Components 
& Supporting Organizations 

GCCS-M 

OPP. 1.12 

Transition Orders Development to Execution 

GCCS-M 

OPP.1.12.1 

Establish Maritime Support Request Process 

MDA 

OPP.1.12.2 

Identify Maritime Support Requirements 

JADOCS 

OPP. 1.12.3 

Coordinate Maritime Support Requests 

JADOCS 

OPP. 1.12.4 

Adjudicate Maritime Support Requests 

JADOCS 

OPP.1.12.5 

Determine Need to Modify COA 

JADOCS, SCOPES, SBMCS, 
GIANT 

OPP. 1.12.6 

Synchronize Tactical Plans & Tasks 

DJC2 

OPP.1.12.7 

Make Maritime Support Requests Visible/Accessible 

CANES 

OPP.2.1 

Analyze Existing OPORD for Operational 

Environment Requirements 

JCRE 

OPP.2.3 

Analyze Operational Environment Control Measure 
Requests 

JCRE, IWS, MIPS 

OPP.2.5 

Develop Initial Set of Operational Environment 

Control Measures 

JCRE 

OPP.2.6 

Designate Operational Environment Control Sectors 

CNDE, CANES, NCES 

OPP.2.7 

Designate Sector Operational Environment Control 
Authorities 

CNDE, CANES, NCES 

OPP.2.8 

Establish Operational Environment Change Request 
Procedures 

CNDE, CANES, NCES 

OPP.2.9 

Compile Operational Environment Control Plan 

CNDE, CANES, NCES 

OPP.2.4 

Component Sub Control Request and Control 
Discussions 

JCRE, IWS, MIPS 
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Table 10 - Systems Allocated to Operational Planning Functions (continued) 


Functions 

Systems 

OPP.3.1 

Assess CDRs Guidance for 10 Implications 

DJC2, VISION 

OPP.3.2 

Determine Most Appropriate Methods to Reach IO 
Objectives 

JADOCS, VISION 

OPP.3.3 

Coordinate Operations Security 

VISION 

OPP.3.4 

Coordinate Psychological Operations 

VISION 

OPP.3.5 

Coordinate Computer Network Operations 

VISION 

OPP.3.6 

Coordinate Electronic Warfare 

VISION 

OPP.3.7 

Coordinate Military Deception 

VISION 

OPP.3.8 

Integrate Information Operations Plans 

RADIANT MERCURY 

OPP.3.9 

Develop IO Annex C 

VISION 

OPP.4.1 

Establish Exercise Concept 

JSIPS 

OPP.4.2 

Assign Personnel/Resources to Exercise 

DJC2 

OPP.4.3 

Develop Participant Instructions 

DJC2 

OPP.4.4 

Develop Master Scenario Event List 

ExMan, JSIPS 

OPP.4.5 

Monitor Exercise Events 

ExMan, JSIPS 

OPP.4.6 

Evaluate Exercise 

ExMan, JSIPS 

OPP.4.7 

Document Exercise Results 

ExMan, JSIPS 

OPP.5.1 

Develop Staff Estimate 

JSIPS 

OPP.5.2 

Identify Movement Requirement 

JCRE 

OPP.5.2.1 

Estimate Lift Requirements 

GCCS-M 

OPP.5.2.2 

Describe Requirements in Logistics Terms 

JCRE 

OPP.5.2.3 

Estimate Transportation Requirements 

GCSS-CC/JTF, CFAST 

OPP.5.2.4 

Submit Transportation Requirements & Report 

GCSS-CC/JTF, CFAST 

OPP.5.3 

Identify Transportation Requirements 

GCSS-CC/JTF, CFAST 

OPP.5.4 

Assess Logistical Capability Organic/Inorganic 
Requirement 

GCSS-CC/JTF, CFAST 

OPP.5.4.1 

Anticipate Capabilities & Logistics Needs 

GCSS-CC/JTF, CFAST 

OPP.5.4.2 

Develop Logistics COA 

GCSS-CC/JTF, CFAST 

OPP.5.4.3 

Monitor Strategic/Operational Tactical Situation 

GCSS-CC/JTF, CFAST 

OPP.5.4.4 

Develop & Maintain Logistics COP 

GCSS-CC/JTF, CFAST 

OPP.5.4.5 

Coordinate Field service Requirements 

GCSS-CC/JTF, CFAST 

OPP.5.8 

Maintain Logistics Knowledge Base 

GCSS-CC/JTF, CFAST 

OPP.5.9 

Terminate Sustainment 

GCSS-CC/JTF, CFAST 

OPP.5.5 

Prioritize & Time Phase Requirements 

GCCS-I3 

OPP.5.6 

Prepare Transportation Plans/Orders 

GCSS-CC/JTF, CFAST 

OPP.5.6.1 

Plan Transportation Operations 

GCSS-CC/JTF, CFAST 

OPP.5.6.2 

Apportion Transportation 

GCSS-CC/JTF, CFAST 

OPP.5.6.3 

Allocate Transportation 

GCSS-CC/JTF, CFAST 

OPP.5.6.4 

Establish/Manage Transportation Request Process 

GCSS-CC/JTF, CFAST 

OPP.5.6.5 

Validate Transportation Request 

GCSS-CC/JTF, CFAST 

OPP.5.6.6 

Task Transportation Assets 

GCSS-CC/JTF, CFAST 

OPP.5.7 

Plan & Coordinate Embarkation/Debarkation 

GCSS-CC/JTF, CFAST 

OPP.5.7.1 

Prepare Forces for Movement 

GCSS-CC/JTF, CFAST 

OPP.5.7.2 

Establish Movement Criteria 

GCSS-CC/JTF, CFAST 

OPP.5.7.3 

Coordinate Movement 

GCSS-CC/JTF, CFAST 

OPP.5.7.4 

Validate Shipment 

GCSS-CC/JTF, CFAST 

OPP.5.10 

Redeployment 

GCSS-CC/JTF, CFAST 

OPP.6.1 

Examine Space Resources 

SCOPES 

OPP.6.2 

Identify Space Assumptions 

JWS 
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Table 10 - Systems Allocated to Operational Planning Functions (continued) 


Functions 

Systems 

OPP.6.3 

Analyze Space Capability 

JWS 

OPP.6.4 

Analyze Foreign Space Reliance 

JWS 

OPP.6.5 

Identify Political Constraints 

JWS 

OPP.6.6 

Develop Space Tactics 

JWS 

OPP.6.7 

Define Space Responsibilities 

JWS 

OPP.6.8 

Identify Space Logistics Requirements 

JWS 

OPP.6.9 

Identify Space Augmentation Requirements 

JWS 

OPP.6.10 

Integrate Space Plan 

JWS 

OPP.7.1 

Establish Salvage & Equipment Retrograde Measures 

GCSS-CC/JTF, CFAST, JCRE 

OPP.7.2 

Send Equipment Retrograde Information 

GCSS-CC/JTF, CFAST, JCRE 

OPP.7.3 

Identify Recoverable or Salvageable Gear 

GCSS-CC/JTF, CFAST, JCRE 

OPP.7.4 

Coordinate & Conduct Equipment Recovery 

GCSS-CC/JTF, CFAST, JCRE 


Table 11 - Systems Allocated to Manage Information Functions 


Functions 

Systems 

MI. 1.1 

Ensure Authorized Entities & Information Used 

Capability Gap 

MI. 1.2 

Adapt info Sharing to Accommodate Evolving Needs 

Capability Gap 

MI. 1.3 

Manage Information Management Cell 

Capability Gap 

MI. 1.3.1 

Manage Workgroup Managers (embedded/shared) 

Capability Gap 

MI.1.3.2 

Provide Overall Info-Related Admin Support 

MSRT 

MI.1.3.3 

Manage Electronic File Plan 

Capability Gap 

MI. 1.3.4 

Manage Messaging Services 

TBMCS, DJC2 

MI.1.3.5 

Manage Suspense Control 

Capability Gap 

MI.1.3.6 

Provide Component IM Cell Services 

Capability Gap 

MI. 1.4 

Provide/Publish Data/Information to Net-Centric 
Environment 

CNDE, CANES 

MI. 1.4.1 

Generate Discovery Metadata 

CMA 

MI. 1.4.2 

Associate Semantic and Structural Metadata 

CNDE, CANES, CMA 

MI. 1.4.3 

Identify Data/Information Requirements 

COLISEUM 

MI. 1.4.4 

Prioritize Data/Information Requirements 

MSRT 

MI. 1.4.5 

Designate Reporting Requirements 

COLISEUM 

MI. 1.4.6 

Request Data/Information 

MSRT 

MI.1.4.7 

Make Data/Information Requirements Visible & 
Accessible 

MDA 

MI. 1.4.8 

Develop Data/Information 

Capability Gap 

MI. 1.4.9 

Publish Data/Information 

NCES 

MI. 1.5 

Conduct Data Management 

CNDE, CANES 

MI. 1.5.1 

Establish Database Management Procedures 

C2PC, TDBM, TCO 

MI.1.5.2 

Conduct Distributed Archive 

CNDE, CANES 

MI. 1.5.3 

Determine Information Pedigree 

Capability Gap 

MI. 1.5.4 

Maintain Information Pedigree 

Capability Gap 

MI. 1.5.5 

Catalogue Information 

CMMA 

MI.1.5.6 

Store Information 

CANES/NCES 

MI.1.5.7 

Dispose of Information 

CMMA 

MI. 1.6 

Capture, Obtain & Distribute Lessons Learned 

IWS 

MI. 1.7 

Establish Digital Rules of Protocol 

Capability Gap 
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Table 11 - Systems Allocated to Manage Information Functions (continued) 


Functions 

Systems 

MI. 1.8 

Collect Data Information 

CMMA, GFM 

MI. 1.8.1 

Identify Data/Information Assets 

CMA 

MI. 1.8.2 

Prioritize Data/Information Assets 

CMA 

MI. 1.8.3 

Identify Subscription 

Capability Gap 

MI. 1.8.4 

Request Subscription 

Capability Gap 

MI.1.8.5 

Access Data/Information 

CNDE, CANES 

MI. 1.8.6 

Evaluate Subscribed Data/Information 

Capability Gap 

MI. 1.8.7 

Update Subscription 

Capability Gap 

MI.1.8.8 

Formulate Discovery Search 

Capability Gap 

MI.1.8.9 

Discover Services 

NCES 

MI. 1.9 

Document Info Requirements/General Procedures 

NCES 

MI. 1.10 

Process Data/Information Distributively 

CNDE, CANES 

MI. 1.10.1 

Filter Data/Information 

GALE-Lite 

MI. 1.10.2 

Deconflict Data/Information 

COLISEUM 

MI.1.10.3 

Aggregate Data/Information 

CNDE, CANES 

MI. 1.10.4 

Correlate Data/Information 

NCCT, C2PC 

MI.1.10.5 

Perform Data/Information Transformation 

DCTS 

MI.1.10.6 

Integrate/Fuse Data/Information 

MDA 

MI.1.10.7 

Label Data/Information 

Radiant Mercury, CENTRIXS 

MI. 1.11 

Share Information Across Forces, COIs & 

Communities of Practice 

MDA, NCES 

MI.1.12 

Determine if Info Sharing Meets COIs & CofPs Needs 

MDA 

MI.2.1 

Develop Procedures for RFI Submission 

MASTER, NCES, NIPRNET, 
SIPRNET 

MI.2.2 

Implement RFI Procedures 

MASTER, NCES, NIPRNET, 
SIPRNET 

MI.2.3 

Validate RFI 

MASTER, NCES, NIPRNET, 
SIPRNET 

MI.2.4 

Track RFIs 

MASTER, NCES, NIPRNET, 
SIPRNET 

MI.2.5 

Draft Response to RFI 

MASTER, NCES, NIPRNET, 
SIPRNET 

MI.2.6 

Submit RFI to HHQ 

MASTER, NCES, NIPRNET, 
SIPRNET 

MI.2.7 

Disseminate RFI Response 

MASTER, NCES, NIPRNET, 
SIPRNET 

MI.3.1 

Provide Information Governance 

CMMA 

MI. 3.2 

Plan Information Management 

GCCS 

MI. 3.4 

Compile IMP Input 

GCCS 

MI.3.5 

Approve Component IMP 

IWS, NIPRNET, SIPRNET, 

NCES 

MI.3.3 

Coordinate IMP 

Capability Gap 

MI.4.1 

Assess Battle Rhythm 

GCCS, DRRS, DJC2 

MI.4.2 

Align with HHQ Battle Rhythms 

NCES 

MI.4.3 

Adjust Battle Rhythm 

C2PC, NCES 

MI.4.4 

Approve /Document Commander's Battle Rhythm 

NCES 

MI.5.1 

Identify C2 & Communications Resource Requirements 

GCCS-M 

MI.5.2 

Tailor C2 Systems & Communications Resources as 
Required 

DJC2 

MI.5.2.5 

Manage Net-Centric Environment Operations 

CNDE, CANES 
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Table 11 - Systems Allocated to Manage Information Functions (continued) 


Functions 

Systems 

MI.5.3 

Coordinate C2 & Communications Resource 
Requirements 

GCCS-M 

MI.5.4 

Promulgate Force Communications Plan 

VisIOn 

MI.5.5 

Locate Service 

GCSS-CC/JTF/JTF 

MI.5.6 

Connect to Service 

GCSS-CC/JTF/JTF 

MI.5.7 

Login to Service 

GCSS-CC/JTF/JTF 

MI.5.8 

Access Authorized Service 

GCSS-CC/JTF/JTF 

MI.5.9 

Manage Net-Centric Environment Operations 

CNDE, CANES, CENTRIXS 

MI.5.10 

Monitor Component Comm Links & Networks 

CENTRIXS, NERMS 

MI.6.1 

Provide Computer Network Defense Services 

Capability Gap 

MI.6.2 

Configure Protection Capabilities 

NIPRNETnet, SIPRNETnet 

MI.6.3 

Coordinate Computer Network Operations 

CENTRIXS 

MI.6.4 

Monitor Information Environment 

CENTRIXS 

MI.6.5 

Detect Unauthorized Action 

NIPRNETnet, SIPRNETnet, 
NERMS 

MI.6.6 

Analyze Network Anomalies 

CENTRIX S.NIPRNET net, 
SIPRNETnet 

MI.6.7 

Respond to Network Incident 

NIPRNETnet, SIPRNETnet 


Table 12 - Systems Allocated to Establish Headquarters Functions 


Functions 

Systems 

EHQ.1.1 

Establish Appropriate Organizational Relationships 

GCCS-M 

EHQ.1.6 

Connect & Interface with Non-DoD Organizations 

GCCS-M 

EHQ.1.7 

Establish Role-Based Knowledge Framework 

GCCS-M 

EHQ.1.8 

Form Distributed Teams/COIs/CofP 

GCCS-M, GCSS 

EHQ. 1.8.1 

Access Subject Matter Expert & Essential 

Information 

GCCS-M, GCSS 

EHQ. 1.8.2 

Identify COI/CofP 

GCCS-M 

EHQ. 1.8.3 

Establish COI/CofP 

GCCS-M 

EHQ. 1.8.4 

Develop COI/CofP Charter 

GCCS-M 

EHQ. 1.8.5 

Prioritize Information Sharing Capabilities 

GCCS-M, GCSS 

EHQ.1.8.6 

Identify Related COIs/CofPs 

GCCS-M, GCSS 

EHQ. 1.8.7 

Advertise COI/CofP 

GCCS-M, GCSS 

EHQ.1.8.8 

Provide COI/CofP Environment 

GCCS-M, GCSS 

EHQ. 1.8.9 

Participate in COI/CofP 

GCCS-M, GCSS 

EHQ.1.8.10 

Manage & Govern COI/CofP 

GCCS-M, GCSS 

EHQ. 1.9 

Manage Battle Rhythm 

GCCS-M, GCSS 

EHQ. 1.10 

Implement Best Practices 

NCES, NIPRNETNET, 
SIPRNETNET, VTC 

EHQ. 1.2 

Allocate Decision Authority/Rights 

GCCS-M, GCCS-J, CENTRIX- 
M 

EHQ. 1.3 

Delegate Organizational Authority for Mission 
Planning & Execution 

GCCS-M, GCCS-J, CENTRIX- 
M 

EHQ. 1.4 

Deploy MOC Forward Element 

GCSS, GCCS-M, DJC2, C2PC, 
GCCS-J 

EHQ. 1.4.1 

Identify Forward Element Requirements 

GCSS, GCCS-M, DJC2 
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Table 12 - Systems Allocated to Establish Headquarters Functions (continued) 


Functions 

Systems 

EHQ. 1.4.2 

Survey Prospective Deployment Site 

GCSS, GCCS-M, C2PC, DJC2 

EHQ. 1.4.3 

Develop/Update Threat Assessment 

GCSS, GCCS-M, DJC2 

EHQ. 1.4.4 

Develop/Update Vulnerability Assessment 

GCSS, GCCS-M, DJC2 

EHQ. 1.4.5 

Develop Criticality Assessment 

GCSS, GCCS-M, DJC2 

EHQ. 1.4.6 

Plan for Host Nation Support 

GCCS-J 

EHQ. 1.4.7 

Establish & Coordinate Security Procedures for 

Theater Forces & Means 

GCSS, GCCS-M, DJC2 

EHQ. 1.4.8 

Establish Collaboration Sessions on the Fly during 
Operations 

GCSS, GCCS-M, NCES 

EHQ. 1.4.9 

Manage Means of Communicating Operational 
Information 

GCSS, GCCS-M 

EHQ. 1.4.10 

Assess Effectiveness of C4 Systems 

GCSS, GCCS-M 

EHQ. 1.4.11 

Obtain Lodging for Personnel 

DTS 

EHQ. 1.5 

Transition Role of HQ 

GCCS-M 

EHQ.1.5.1 

Establish Command Transition Criteria & Procedures 

GCCS-M 

EHQ.1.5.2 

Establish Command Relationships to Enable 
Appropriate Coordination 

GCCS-M 

EHQ.1.5.3 

Develop Joint Force Liaison/Augmentee Structure 

GCCS-M, GCCS-J 

EHQ.1.5.4 

Establish Internal Staff Collaboration Structures & 
Processes 

GCCS-M 

EHQ.1.5.5 

Define Specific Procedures for Allocating 
Capabilities/Forces 

GCCS-M 

EHQ.1.5.6 

Define Specific Procedures for Exercising 
Capabilities/Forces 

GCCS-M 

EHQ.1.5.7 

Define Specific Procedures for Tasking 
Capabilities/Forces 

GCCS-M 

EHQ.1.5.8 

Define Specific Procedures for Transitioning C2 

GCCS-M 

EHQ. 1.5.9 

Execute C4 Policies & Procedures for the Joint 
Operations Area 

GCCS-J, DCGS-N, TBMCS, 
CENTRIX-M 

EHQ. 1.11 

Sub Component Interagency 

Capability Gap 

EHQ.2.1 

Develop Training Plans and Programs 

GCCS-M 

EHQ.2.2 

Provide/Execute Training forU.S. and Other Nation 
Units and Individuals 

GCCS-M 

EHQ.2.3 

Assess Training 

CENTRIX-M, GCCS-J, NCES 


Table 13 - Systems Allocated to Execute Plans Functions 


Functions 

Systems 

EP.1.1 

Maintain Operational Information & Joint/Naval Forces 
Status 

JADOCS 

EP. 1.1.1 

Monitor Data Feeds to CIP/CTP/COP 

DCGS-N, ADSI, C2BMC 

EP.1.1.2 

Maintain Common Intelligence Picture 

CMMA 

EP.1.1.3 

Integrate Adversary & Friendly Data 

JADOCS 

EP.1.1.4 

Manage Common Tactical Picture (CTP) 

C2PC 

EP.1.1.5 

Integrate Common Tactical Pictures 

C2PC 

EP.1.1.6 

Manage COP Tracks 

C2PC 

EP.1.1.7 

Update COP Information 

C2PC 

EP.1.1.8 

Add Amplifying Info to Tracks 

JADOCS, C2PC 

EP.1.1.9 

Sanitize COP 

C2PC 
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Table 13 - Systems Allocated to Execute Plans Functions (continued) 


Functions 

Systems 

EP.1.1.10 

Disseminate COP 

JADOCS 

EP. 1.1.11 

Assess COP Information 

JADOCS, C2PC 

EP.1.1.12 

Collate COP Information 

JADOCS 

EP. 1.1.13 

View Tailored, Relevant Situational Information 

DCGS-N, JADOCS 

EP. 1.2 

Assure Adequate Control, Tracking & Management of 
Plans & Decisions 

C2PC 

EP. 1.4 

Execute Plans/Orders 

JWICS, SVOIP, M3 

EP. 1.5 

Conduct Operational Movement & Maneuver 

DCGS-N, JADOCS, C2PC 

EP.1.5.1 

Deconflict the Operational Environment 

DCGS-N, JADOCS, C2PC 

EP.1.5.2 

Direct Operational Movement 

JADOCS 

EP. 1.5.3 

Control Movement 

C2PC 

EP.1.5.4 

Provide Joint Total Asset Visibility 

DCGS-N 

EP. 1.5.5 

Provide Status of Deployment Operations 

DCGS-N, JADOCS, C2PC 

EP. 1.5.6 

Conduct Operational Maneuver & Force Positioning 

JADOCS, C2PC 

EP.1.5.7 

Provide Operational Mobility 

JADOCS, C2PC 

EP.1.6 

Monitor Execution & Adapt Operations 

DCGS-N 

EP. 1.6.1 

Monitor Execution of Plans/Orders 

M3, DCGS-N 

EP. 1.6.2 

Manage Risk 

GCCS-M/J 

EP.1.6.3 

Intervene in Subordinate Actions as Needed 

C2PC 

EP. 1.6.4 

Adapt Operations to Changing Situations thru Initiative 
& Self Synchronization 

JADOCS, C2PC 

EP. 1.6.5 

Modify/Revise Procedures & Schedules 

C2PC 

EP.1.6.6 

Respond to Emerging Requests for Support from 
Peer/Subordinate Commands 

C2PC 

EP.1.3 

Synchronize Execution Across All Domains 

JADOCS, C2PC 

EP. 1.7 

Collaboratively, Rapidly Replan Operations 

C2PC 

EP.2.1 

Approve Planning Guidance 

C2PC 

EP.2.2 

Develop Priority of Effort 

GCCS-M/J/I3 

EP.2.3 

Shape Guidance w/Mission Partners' Concerns in Mind 

GCCS-J 

EP.2.4 

Develop the Commander's Planning Guidance 

GCCS-M/J/I3 

EP.2.5 

Make Commander's Planning Guidance 
Visible/Accessible 

NCES 

EP.3.1 

Request Health Services Support 

NCES 

EP.3.2 

Coordinate Health Service Allocation 

DCGS-N, NCES 

EP.3.3 

Submit Patient Movement Request 

M3 

EP.3.4 

Transmit MEDEVAC OPS Info 

M3 

EP.3.5 

Receive MEDEVAC OPS Coordination Info 

NCES, M3 

EP.3.6 

Coordinate Patient Movement 

GCCS-M/J, NCES 

EP.3.6.1 

Administratively & Clinically Validate Patient 

Capability Gap 

EP.3.6.2 

Locate Appropriate Medical Facilities 

NCES, NIPRNET, SIPRNET 

EP.3.6.3 

Identify Evacuation Resources 

GCCS-M/J, NCES, DCGS-N 

EP.3.6.4 

Integrate & Synchronize the Resources for Patient 
Evacuation 

GCCS-M/J 

EP.3.6.5 

Plan Evacuation Route 

Falconview 

EP.3.6.6 

Provide Patient Attendants & Movement Items 

Capability Gap 

EP.3.6.7 

Move Patient 

Capability Gap 

EP.3.6.8 

Provide In-transit Patient Visibility 

DCGS-N, NCES 

EP.3.7 

Conduct Patient Evacuation 

Capability Gap 

EP.3.8 

Obtain & Analyze Medical Information 

NCES 


59 




Table 13 - Systems Allocated to Execute Plans Functions (continued) 


Functions 

Systems 

EP.3.9 

Manage Blood Program in Area of Operations 

C2PC 

EP.4.1 

Receive Request for Frequency Assignment 

IWS, Outlook 

EP.4.2 

Analyze and Ensure Spectrum Availability 

AESOP 

EP.4.3 

Develop Electromagnetic Frequency Assignments 

AESOP, C2PC 

EP.4.5 

Resolve Interference & Electromagnetic Effects Issues 

AESOP 

EP.4.4 

Deconflict Spectrum Usage 

IWS, Outlook 

EP.5.1 

Monitor & Analyze Current & Projected Unit Personnel 
Strengths 

DRRS 

EP.5.2 

Initiate Personnel Staff Estimates 

IWS, NCES, NIPRNET, 

SIPRNET, VTC 

EP.5.3 

Determine Effects of Personnel Strengths on Assigned 
Operations 

DRRS 

EP.5.4 

Provide Fleadquarters Personnel & Infrastructure 

Capability Gap 

EP.5.4.1 

Receive Personnel Request 

NCES, M3 

EP.5.4.2 

Transmit Personnel Allocation Information 

NCES, M3 

EP.5.4.3 

Provide Augmentation 

Capability Gap 

EP.5.4.4 

Control Throughput of Personnel and MPE/S 

NCES 

EP.5.4.5 

Request/Receive Personnel Information 

NCES 

EP.5.4.6 

Send Personnel Transfer Information 

NCES 

EP.5.5 

Process Manpower Management System Data 

DRRS 

EP.5.6 

Provide Personnel Accounting and Strength Support 

NCES 

EP.5.7 

Provide for Personnel Services 

Capability Gap 

EP.5.8 

Joint Reception Process 

DRRS 

EP.6.9 

Mission Planning & Force Execution 

DCGS-N, ADSI, C2BMC, 
JADOCS 

EP.6.1 

Develop Maritime End State and Objectives 

NCES 

EP.6.2 

Perform Target Development and Priorities 

C2BMC, JADOCS 

EP.6.3 

Capabilities Analysis 

NCES 

EP.6.4 

Develop Operational Targets 

NCCT, JADOCS 

EP.6.5 

Develop Maritime Target List 

NCCT, JADOCS 

EP.6.6 

Provide Maritime Target Process Decision 

NCCT, JADOCS 

EP.6.7 

Provide Target Nominations to Fligher F1Q 

NCCT, C2BMC, JADOCS 

EP.6.8 

Commander's Decision & Force Appointment 

JMPS, C2BMC, JADOCS 

EP.6.10 

Prioritize & Integrate Collection Requirements 

DCGS-N, C2BMC 

EP.6.11 

Conduct Weaponeering 

JADOCS 

EP.6.12 

Conduct Force Allocation & Assessment 

JMPS 

EP.6.13 

Develop Mission Timing & Synchronization 

JMPS 

EP.6.14 

Develop tasking Orders to Maritime Forces 

JMPS 

EP.6.15 

Process JIP TL/JIP CL/Asset Appointment 

Capability Gap 

EP.7.1 

Forecast Vulnerability of Friendly Operations 

SCOPES, SBMCS 

EP.7.2 

Recommend Force Enhancement Options 

SCOPES 

EP.7.3 

Coordinate Space Control Assets 

SCOPES, DMS, GCCS-J 

EP.7.4 

Deconflict Use of DoD Space Systems 

SCOPES, DMS, GCCS-J 

EP.7.5 

Provide Tailored Space Training 

Capability Gap 

EP.7.6 

Distribute Missile Warning Data 

ADSI, C2BMC, DMS, GCCS-J 

EP.8.1 

Develop MOEs for Determining if Collection Tasks 

Are Being Answered 

IWS, NIPRNET, SIPRNET, 

NCES, VTC 

EP.8.2 

Monitor & Evaluate Collection Strategies for 
Effectiveness 

DCGS-N, NCES 
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Table 13 - Systems Allocated to Execute Plans Functions (continued) 


Functions 

Systems 

EP.8.3 

Assess RFI/CR Fulfillment 

NCES 

EP.8.4 

Assess Sensor Grid Status, Configuration, Performance 
& Capabilities 

DCGS-N 

EP.8.6 

Provide Operational Environment Awareness 

Operations Assessment 

DCGS-N 

EP.8.5 

Identify Coverage Gaps & Redundancies, Consider 

RFF 

NCES 

EP.9.1 

Execute Logistics Plans within Assigned Operational 
Area - Classes 1 thru9 

Global Trader, GCSS(Thin) 

EP.9.2 

Develop/Maintain Logistics Base in JOA 

Capability Gap 

EP.9.3 

Anticipate Response to Force Needs 

Global Trader, GCSS(Thin) 

EP.9.4 

Provide for Movement in the Area of Operations 

Global Trader, GCSS(Thin) 

EP.9.5 

Track & Manage Supplies 

Global Trader, NCES, 

GCSS(Thin) 

EP.9.6 

Coordinate Ordnance Requirements 

Global Trader, GCSS(Thin) 

EP.9.7 

Coordinate POL Requirements 

Global Trader, GCSS(Thin) 

EP.9.8 

Provide for Sustainment of Equipment in the JOA 

Global Trader, GCSS(Thin) 

EP.9.8.1 

Predict Repair/Maintenance Requirements 

Capability Gap 

EP.9.8.2 

Sense Repair/Maintenance Requirements 

Capability Gap 

EP.9.8.3 

Monitor Maintenance Capabilities & Status within the 
JOA 

NCES 

EP.9.8.4 

Identify Repair/Maintenance Resources 

NCES 

EP.9.8.5 

Establish Maintenance Priorities 

Global Trader, GCSS(Thin) 

EP.9.8.6 

Receive Maintenance Schedule 

M3, SharePoint, Outlook 

EP.9.8.7 

Provide Maintenance Schedule 

M3, SharePoint, Outlook 

EP.9.8.8 

Provide Shipboard & Mobile Maintenance to Embarked 
Force 

Global Trader, GCSS(Thin) 

EP.9.9 

Coordinate Support for the Forces in the JOA 

Global Trader, C2PC, NCES, 
GCSS(Thin) 

EP.9.9.1 

Receive Supply Allocation Information 

Global Trader, GCSS(Thin) 

EP.9.9.2 

Report Demand & Supply Transactions 

Global Trader, DCGS-N, C2PC, 
GCSS(Thin) 

EP.9.9.3 

Sense Demand for Logistics Resources 

Global Trader, DCGS-N C2PC, 
GCSS(Thin) 

EP.9.9.4 

Analyze Evolving Capabilities & Sustainment 
Requirements 

NCES 

EP.9.9.5 

Process Transportation Request 

Global Trader, DCGS-N, C2PC, 
GCSS(Thin) 

EP.9.9.6 

Schedule/Coordinate Replenishment 

Global Trader, DCGS-N, 
GCSS(Thin) 

EP.9.10 

Monitor Critical Supply Support Capabilities 

Global Trader, DCGS-N, C2PC, 
GCSS(Thin) 

EP.10.2 

Configure Netted Sensor Grid 

Capability Gap 

EP.10.3 

Task Sensor 

Capability Gap 

EP. 10.4 

Collect & Transport Sensor Derived Data 

DCGS-N 

EP.10.4.1 

Collect Data 

DCGS-N 

EP. 10.4.2 

Provide Sensor Data 

DCGS-N 

EP.10.4.3 

Conduct Dynamic Cross-Cuing of Sensor Data 

Capability Gap 

EP.10.4.4 

Provide Sensor Tip-Off 

Capability Gap 

EP. 10.4.5 

Capture Sensor Platform Data 

DCGS-N, GALE-Lite 
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Table 13 - Systems Allocated to Execute Plans Functions (continued) 


Functions 

Systems 

EP.10.5 

Maintain SA of Mission, Tasking & Operational 
Environment 

DCGS-N, C2PC 

EP. 10.1 

Allocate ISR Resources 

JWICS 
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APPENDIX B 

ACRONYMS OF ASSIGNED SYSTEMS 


ADSI 

AESOP 

C2PC 

CANES 

CENTRIX 

CFAST 

CMA 

CNDE 

COLISEUM 

CPOF 

DCGS-N 

DJC2 

DRRS 

ExMan 

GALE 

GCCS 

GCCS-I3 

GCCS-J 

GCCS-M 

GCSS(Thin) 

GCSS-CC/JTF 

GFM 

GIANT 

ISPAN 

IWS 

JADOCS 

JCRE 

IMPS 

JSIPS 

JWS 

M3 


Air Defense Systems Integrator 
Afloat Electromagnetic Spectrum Operations Program 
Command and Control Personal Computer 
Consolidated Afloat Networks and Enterprise Services 
Combined Enterprise Regional Information Exchange System 
Collaborative Force Analysis, Sustainment, and Transportation 
Comprehensive Maritime Awareness 
Consolidated Net Centric Data Environment 

Community On-Line Intelligence System for End Users and Managers 

Command Post of the Future 

Distributed Common Ground System-Navy 

Deployable Joint Command and Control 

Defense Readiness Reporting System 

Exercise Manager 

Generic Area Limitation Environment 
Global Command and Control System 

Global Command and Control System-Integrated Imagery and Intelligence 
Global Command and Control System-Joint 
Global Command and Control System-Maritime 
Global Combat Support System 

Global Combat Support System - Combatant Commander/Joint Task Force 

Global Force Manager 

GPS Interface and Navigation Tool 

Integrated Strategic Planning and Analysis Network 

Information Work Space 

Joint Automated Deep Operations Coordination System 

Joint Collaborative Real Time Engagement 

Joint Mission Planning System 

Joint Service Imagery Processing System 

Joint Warfighting Space 

Multimedia Message Manager 
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MDA 

MIPS 

MSRT 

NCCT 

NCES 

NERMS 

NIPRNet 

SBMCS 

SCOPES 

SIPRNet 

SVOIP 

TDBM 

VISION 

VTC 


APPENDIX B (continued) 

Maritime Domain Awareness 

Maritime Interdiction Integrated Air and Missile Defense Planning 
System 

Maritime Support Request Tool 

Net-Centric Collaborative Targeting 

Net-Centric Enterprise Services 

Navy Emergency Response Management System 

Non-Classified Internet Protocol Router Network 

Space Battle Management Core System 

Space Common Operating Picture and Exploitation System 

Secret Internet Protocol Router Network 

Secret Voice Over Internet Protocol 

Tactical Database Management 

Virtual Integrated Support for Information Operations Environment 
Video Teleconference 
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